Je suis en train de convertir mes tâches cron en minuteries systemd. J'ai utilisé des minuteries pendant quelques années, mais généralement, j'en ai appris juste assez pour effectuer la tâche sur laquelle je travaillais. En faisant des recherches pour cette série systemd, j'ai appris que les temporisateurs systemd ont des capacités très intéressantes.
Comme les tâches cron, les temporisateurs systemd peuvent déclencher des événements (scripts shell et programmes) à des intervalles de temps spécifiés, comme une fois par jour, un jour spécifique du mois (peut-être seulement si c'est un lundi) ou toutes les 15 minutes pendant les heures ouvrables. de 8h à 18h. Les minuteurs peuvent également faire certaines choses que les tâches cron ne peuvent pas faire. Par exemple, une minuterie peut déclencher un script ou un programme pour exécuter un laps de temps spécifique après un événement tel que le démarrage, le démarrage, l'achèvement d'une tâche précédente ou même l'achèvement précédent de l'unité de service appelée par la minuterie.
Temporisateurs de maintenance du système
Lorsque Fedora ou toute distribution basée sur systemd est installée sur un nouveau système, elle crée plusieurs minuteries qui font partie des procédures de maintenance du système qui se déroulent en arrière-plan de tout hôte Linux. Ces minuteurs déclenchent les événements nécessaires aux tâches de maintenance courantes, telles que la mise à jour des bases de données système, le nettoyage des répertoires temporaires, la rotation des fichiers journaux, etc.
À titre d'exemple, je vais examiner certaines des minuteries sur mon poste de travail principal en utilisant le systemctl status *timer commande pour lister toutes les minuteries sur mon hôte. Le symbole astérisque fonctionne de la même manière que pour la globalisation de fichiers, donc cette commande répertorie toutes les unités de minuterie systemd :
[root@testvm1 ~]# systemctl status *timer
● mlocate-updatedb.timer - Updates mlocate database every day
Loaded: loaded (/usr/lib/systemd/system/mlocate-updatedb.timer; enabled; vendor preset: enabled)
Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
Trigger: Fri 2020-06-05 00:00:00 EDT; 15h left
Triggers: ● mlocate-updatedb.service
Jun 02 08:02:33 testvm1.both.org systemd[1]: Started Updates mlocate database every day.
● logrotate.timer - Daily rotation of log files
Loaded: loaded (/usr/lib/systemd/system/logrotate.timer; enabled; vendor preset: enabled)
Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
Trigger: Fri 2020-06-05 00:00:00 EDT; 15h left
Triggers: ● logrotate.service
Docs: man:logrotate(8)
man:logrotate.conf(5)
Jun 02 08:02:33 testvm1.both.org systemd[1]: Started Daily rotation of log files.
● sysstat-summary.timer - Generate summary of yesterday's process accounting
Loaded: loaded (/usr/lib/systemd/system/sysstat-summary.timer; enabled; vendor preset: enabled)
Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
Trigger: Fri 2020-06-05 00:07:00 EDT; 15h left
Triggers: ● sysstat-summary.service
Jun 02 08:02:33 testvm1.both.org systemd[1]: Started Generate summary of yesterday's process accounting.
● fstrim.timer - Discard unused blocks once a week
Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; vendor preset: enabled)
Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
Trigger: Mon 2020-06-08 00:00:00 EDT; 3 days left
Triggers: ● fstrim.service
Docs: man:fstrim
Jun 02 08:02:33 testvm1.both.org systemd[1]: Started Discard unused blocks once a week.
● sysstat-collect.timer - Run system activity accounting tool every 10 minutes
Loaded: loaded (/usr/lib/systemd/system/sysstat-collect.timer; enabled; vendor preset: enabled)
Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
Trigger: Thu 2020-06-04 08:50:00 EDT; 41s left
Triggers: ● sysstat-collect.service
Jun 02 08:02:33 testvm1.both.org systemd[1]: Started Run system activity accounting tool every 10 minutes.
● dnf-makecache.timer - dnf makecache --timer
Loaded: loaded (/usr/lib/systemd/system/dnf-makecache.timer; enabled; vendor preset: enabled)
Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
Trigger: Thu 2020-06-04 08:51:00 EDT; 1min 41s left
Triggers: ● dnf-makecache.service
Jun 02 08:02:33 testvm1.both.org systemd[1]: Started dnf makecache –timer.
● systemd-tmpfiles-clean.timer - Daily Cleanup of Temporary Directories
Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-clean.timer; static; vendor preset: disabled)
Active: active (waiting) since Tue 2020-06-02 08:02:33 EDT; 2 days ago
Trigger: Fri 2020-06-05 08:19:00 EDT; 23h left
Triggers: ● systemd-tmpfiles-clean.service
Docs: man:tmpfiles.d(5)
man:systemd-tmpfiles(8)
Jun 02 08:02:33 testvm1.both.org systemd[1]: Started Daily Cleanup of Temporary Directories.
Chaque minuteur est associé à au moins six lignes d'informations :
- La première ligne contient le nom du fichier du minuteur et une brève description de son objectif.
- La deuxième ligne affiche l'état de la minuterie, s'il est chargé, le chemin d'accès complet au fichier de l'unité de minuterie et le préréglage du fournisseur.
- La troisième ligne indique son statut actif, qui inclut la date et l'heure auxquelles le minuteur est devenu actif.
- La quatrième ligne contient la date et l'heure auxquelles le minuteur sera déclenché ensuite et une heure approximative jusqu'à ce que le déclenchement se produise.
- La cinquième ligne affiche le nom de l'événement ou du service déclenché par le minuteur.
- Certains fichiers d'unité systemd (mais pas tous) ont des pointeurs vers la documentation pertinente. Trois des minuteries de la sortie de ma machine virtuelle ont des pointeurs vers la documentation. Il s'agit d'une belle (mais facultative) petite donnée.
- La dernière ligne est l'entrée de journal pour l'instance la plus récente du service déclenchée par le minuteur.
En fonction de votre hôte, vous aurez probablement un ensemble de minuteries différent.
Créer un minuteur
Bien que nous puissions déconstruire une ou plusieurs des minuteries existantes pour apprendre comment elles fonctionnent, créons notre propre unité de service et une unité de minuterie pour la déclencher. Nous allons utiliser un exemple assez trivial afin de garder cela simple. Une fois que nous aurons terminé, il sera plus facile de comprendre le fonctionnement des autres minuteurs et de déterminer ce qu'ils font.
Tout d'abord, créez un service simple qui exécutera quelque chose de basique, comme le free commande. Par exemple, vous souhaiterez peut-être surveiller la mémoire disponible à intervalles réguliers. Créez le myMonitor.service suivant fichier d'unité dans le /etc/systemd/system annuaire. Il n'a pas besoin d'être exécutable :
# This service unit is for testing timer units
# By David Both
# Licensed under GPL V2
#
[Unit]
Description=Logs system statistics to the systemd journal
Wants=myMonitor.timer
[Service]
Type=oneshot
ExecStart=/usr/bin/free
[Install]
WantedBy=multi-user.target
Examinons maintenant l'état et testons notre unité de service pour nous assurer qu'elle fonctionne comme prévu.
[root@testvm1 system]# systemctl status myMonitor.service
● myMonitor.service - Logs system statistics to the systemd journal
Loaded: loaded (/etc/systemd/system/myMonitor.service; disabled; vendor preset: disabled)
Active: inactive (dead)
[root@testvm1 system]# systemctl start myMonitor.service
[root@testvm1 system]#
Où est la sortie ? Par défaut, la sortie standard (STDOUT ) des programmes exécutés par les unités de service systemd est envoyé au journal systemd, qui laisse un enregistrement que vous pouvez consulter maintenant ou plus tard, jusqu'à un certain point. (J'examinerai la journalisation systemd et les stratégies de rétention dans un futur article de cette série.) Consultez le journal spécifiquement pour votre unité de service et pour aujourd'hui uniquement. Le -S option, qui est la version courte de --since , permet de spécifier la période de temps que le journalctl l'outil doit rechercher des entrées. Ce n'est pas parce que vous ne vous souciez pas des résultats précédents - dans ce cas, il n'y en aura pas - c'est pour raccourcir le temps de recherche si votre hébergeur fonctionne depuis longtemps et a accumulé un grand nombre d'entrées dans la revue :
[root@testvm1 system]# journalctl -S today -u myMonitor.service
-- Logs begin at Mon 2020-06-08 07:47:20 EDT, end at Thu 2020-06-11 09:40:47 EDT. --
Jun 11 09:12:09 testvm1.both.org systemd[1]: Starting Logs system statistics to the systemd journal...
Jun 11 09:12:09 testvm1.both.org free[377966]: total used free shared buff/cache available
Jun 11 09:12:09 testvm1.both.org free[377966]: Mem: 12635740 522868 11032860 8016 1080012 11821508
Jun 11 09:12:09 testvm1.both.org free[377966]: Swap: 8388604 0 8388604
Jun 11 09:12:09 testvm1.both.org systemd[1]: myMonitor.service: Succeeded.
[root@testvm1 system]#
Une tâche déclenchée par un service peut être un programme unique, une série de programmes ou un script écrit dans n'importe quel langage de script. Ajoutez une autre tâche au service en ajoutant la ligne suivante à la fin du [Service] section du myMonitor.service fichier unité :
ExecStart=/usr/bin/lsblkRedémarrez le service et vérifiez le journal pour les résultats, qui devraient ressembler à ceci. Vous devriez voir les résultats des deux commandes dans le journal :
Jun 11 15:42:18 testvm1.both.org systemd[1]: Starting Logs system statistics to the systemd journal...
Jun 11 15:42:18 testvm1.both.org free[379961]: total used free shared buff/cache available
Jun 11 15:42:18 testvm1.both.org free[379961]: Mem: 12635740 531788 11019540 8024 1084412 11812272
Jun 11 15:42:18 testvm1.both.org free[379961]: Swap: 8388604 0 8388604
Jun 11 15:42:18 testvm1.both.org lsblk[379962]: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
Jun 11 15:42:18 testvm1.both.org lsblk[379962]: sda 8:0 0 120G 0 disk
Jun 11 15:42:18 testvm1.both.org lsblk[379962]: ├─sda1 8:1 0 4G 0 part /boot
Jun 11 15:42:18 testvm1.both.org lsblk[379962]: └─sda2 8:2 0 116G 0 part
Jun 11 15:42:18 testvm1.both.org lsblk[379962]: ├─VG01-root 253:0 0 5G 0 lvm /
Jun 11 15:42:18 testvm1.both.org lsblk[379962]: ├─VG01-swap 253:1 0 8G 0 lvm [SWAP]
Jun 11 15:42:18 testvm1.both.org lsblk[379962]: ├─VG01-usr 253:2 0 30G 0 lvm /usr
Jun 11 15:42:18 testvm1.both.org lsblk[379962]: ├─VG01-tmp 253:3 0 10G 0 lvm /tmp
Jun 11 15:42:18 testvm1.both.org lsblk[379962]: ├─VG01-var 253:4 0 20G 0 lvm /var
Jun 11 15:42:18 testvm1.both.org lsblk[379962]: └─VG01-home 253:5 0 10G 0 lvm /home
Jun 11 15:42:18 testvm1.both.org lsblk[379962]: sr0 11:0 1 1024M 0 rom
Jun 11 15:42:18 testvm1.both.org systemd[1]: myMonitor.service: Succeeded.
Jun 11 15:42:18 testvm1.both.org systemd[1]: Finished Logs system statistics to the systemd journal.
Maintenant que vous savez que votre service fonctionne comme prévu, créez le fichier d'unité de minuterie, myMonitor.timer file dans /etc/systemd/system , et ajoutez ce qui suit :
# This timer unit is for testing
# By David Both
# Licensed under GPL V2
#
[Unit]
Description=Logs some system statistics to the systemd journal
Requires=myMonitor.service
[Timer]
Unit=myMonitor.service
OnCalendar=*-*-* *:*:00
[Install]
WantedBy=timers.target
Le OnCalendar spécification de l'heure dans le fichier myMonitor.timer file , *-*-* *:*:00 , devrait déclencher le minuteur pour exécuter le myMonitor.service unité toutes les minutes. Je vais explorer OnCalendar paramètres un peu plus loin dans cet article.
Pour l'instant, observez toutes les entrées de journal relatives à l'exécution de votre service lorsqu'il est déclenché par le minuteur. Vous pouvez également suivre le chronomètre, mais suivre le service vous permet de voir les résultats en temps quasi réel. Exécutez journalctl avec le -f option (suivre) :
[root@testvm1 system]# journalctl -S today -f -u myMonitor.service
-- Logs begin at Mon 2020-06-08 07:47:20 EDT. --
Démarrez mais n'activez pas le minuteur et voyez ce qui se passe après un certain temps :
[root@testvm1 ~]# systemctl start myMonitor.service
[root@testvm1 ~]#
Un résultat apparaît tout de suite, et les suivants arrivent à des intervalles d'une minute. Regardez le journal pendant quelques minutes et voyez si vous remarquez les mêmes choses que moi :
[root@testvm1 system]# journalctl -S today -f -u myMonitor.service
-- Logs begin at Mon 2020-06-08 07:47:20 EDT. --
Jun 13 08:39:18 testvm1.both.org systemd[1]: Starting Logs system statistics to the systemd journal...
Jun 13 08:39:18 testvm1.both.org systemd[1]: myMonitor.service: Succeeded.
Jun 13 08:39:19 testvm1.both.org free[630566]: total used free shared buff/cache available
Jun 13 08:39:19 testvm1.both.org free[630566]: Mem: 12635740 556604 10965516 8036 1113620 11785628
Jun 13 08:39:19 testvm1.both.org free[630566]: Swap: 8388604 0 8388604
Jun 13 08:39:18 testvm1.both.org systemd[1]: Finished Logs system statistics to the systemd journal.
Jun 13 08:39:19 testvm1.both.org lsblk[630567]: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
Jun 13 08:39:19 testvm1.both.org lsblk[630567]: sda 8:0 0 120G 0 disk
Jun 13 08:39:19 testvm1.both.org lsblk[630567]: ├─sda1 8:1 0 4G 0 part /boot
Jun 13 08:39:19 testvm1.both.org lsblk[630567]: └─sda2 8:2 0 116G 0 part
Jun 13 08:39:19 testvm1.both.org lsblk[630567]: ├─VG01-root 253:0 0 5G 0 lvm /
Jun 13 08:39:19 testvm1.both.org lsblk[630567]: ├─VG01-swap 253:1 0 8G 0 lvm [SWAP]
Jun 13 08:39:19 testvm1.both.org lsblk[630567]: ├─VG01-usr 253:2 0 30G 0 lvm /usr
Jun 13 08:39:19 testvm1.both.org lsblk[630567]: ├─VG01-tmp 253:3 0 10G 0 lvm /tmp
Jun 13 08:39:19 testvm1.both.org lsblk[630567]: ├─VG01-var 253:4 0 20G 0 lvm /var
Jun 13 08:39:19 testvm1.both.org lsblk[630567]: └─VG01-home 253:5 0 10G 0 lvm /home
Jun 13 08:39:19 testvm1.both.org lsblk[630567]: sr0 11:0 1 1024M 0 rom
Jun 13 08:40:46 testvm1.both.org systemd[1]: Starting Logs system statistics to the systemd journal...
Jun 13 08:40:46 testvm1.both.org free[630572]: total used free shared buff/cache available
Jun 13 08:40:46 testvm1.both.org free[630572]: Mem: 12635740 555228 10966836 8036 1113676 11786996
Jun 13 08:40:46 testvm1.both.org free[630572]: Swap: 8388604 0 8388604
Jun 13 08:40:46 testvm1.both.org lsblk[630574]: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
Jun 13 08:40:46 testvm1.both.org lsblk[630574]: sda 8:0 0 120G 0 disk
Jun 13 08:40:46 testvm1.both.org lsblk[630574]: ├─sda1 8:1 0 4G 0 part /boot
Jun 13 08:40:46 testvm1.both.org lsblk[630574]: └─sda2 8:2 0 116G 0 part
Jun 13 08:40:46 testvm1.both.org lsblk[630574]: ├─VG01-root 253:0 0 5G 0 lvm /
Jun 13 08:40:46 testvm1.both.org lsblk[630574]: ├─VG01-swap 253:1 0 8G 0 lvm [SWAP]
Jun 13 08:40:46 testvm1.both.org lsblk[630574]: ├─VG01-usr 253:2 0 30G 0 lvm /usr
Jun 13 08:40:46 testvm1.both.org lsblk[630574]: ├─VG01-tmp 253:3 0 10G 0 lvm /tmp
Jun 13 08:40:46 testvm1.both.org lsblk[630574]: ├─VG01-var 253:4 0 20G 0 lvm /var
Jun 13 08:40:46 testvm1.both.org lsblk[630574]: └─VG01-home 253:5 0 10G 0 lvm /home
Jun 13 08:40:46 testvm1.both.org lsblk[630574]: sr0 11:0 1 1024M 0 rom
Jun 13 08:40:46 testvm1.both.org systemd[1]: myMonitor.service: Succeeded.
Jun 13 08:40:46 testvm1.both.org systemd[1]: Finished Logs system statistics to the systemd journal.
Jun 13 08:41:46 testvm1.both.org systemd[1]: Starting Logs system statistics to the systemd journal...
Jun 13 08:41:46 testvm1.both.org free[630580]: total used free shared buff/cache available
Jun 13 08:41:46 testvm1.both.org free[630580]: Mem: 12635740 553488 10968564 8036 1113688 11788744
Jun 13 08:41:46 testvm1.both.org free[630580]: Swap: 8388604 0 8388604
Jun 13 08:41:47 testvm1.both.org lsblk[630581]: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
Jun 13 08:41:47 testvm1.both.org lsblk[630581]: sda 8:0 0 120G 0 disk
Jun 13 08:41:47 testvm1.both.org lsblk[630581]: ├─sda1 8:1 0 4G 0 part /boot
Jun 13 08:41:47 testvm1.both.org lsblk[630581]: └─sda2 8:2 0 116G 0 part
Jun 13 08:41:47 testvm1.both.org lsblk[630581]: ├─VG01-root 253:0 0 5G 0 lvm /
Jun 13 08:41:47 testvm1.both.org lsblk[630581]: ├─VG01-swap 253:1 0 8G 0 lvm [SWAP]
Jun 13 08:41:47 testvm1.both.org lsblk[630581]: ├─VG01-usr 253:2 0 30G 0 lvm /usr
Jun 13 08:41:47 testvm1.both.org lsblk[630581]: ├─VG01-tmp 253:3 0 10G 0 lvm /tmp
Jun 13 08:41:47 testvm1.both.org lsblk[630581]: ├─VG01-var 253:4 0 20G 0 lvm /var
Jun 13 08:41:47 testvm1.both.org lsblk[630581]: └─VG01-home 253:5 0 10G 0 lvm /home
Jun 13 08:41:47 testvm1.both.org lsblk[630581]: sr0 11:0 1 1024M 0 rom
Jun 13 08:41:47 testvm1.both.org systemd[1]: myMonitor.service: Succeeded.
Jun 13 08:41:47 testvm1.both.org systemd[1]: Finished Logs system statistics to the systemd journal.
Assurez-vous de vérifier l'état du minuteur et du service.
En savoir plus sur les administrateurs système
- Activer le blog Sysadmin
- L'entreprise automatisée :un guide pour gérer l'informatique avec l'automatisation
- Livre électronique :Automatisation Ansible pour les administrateurs système
- Témoignages du terrain :guide de l'administrateur système sur l'automatisation informatique
- eBook :Un guide de Kubernetes pour les SRE et les administrateurs système
- Derniers articles sur l'administrateur système
Vous avez probablement remarqué au moins deux choses dans le journal. Tout d'abord, vous n'avez rien de spécial à faire pour provoquer le STDOUT depuis le ExecStart déclencheurs dans myMonitor.service unité à stocker dans le journal. Cela fait partie de l'utilisation de systemd pour exécuter des services. Cependant, cela signifie que vous devrez peut-être faire attention à l'exécution de scripts à partir d'une unité de service et à la quantité de STDOUT ils génèrent.
La deuxième chose est que la minuterie ne se déclenche pas exactement à la minute à :00 secondes ou même exactement à une minute de l'instance précédente. C'est intentionnel, mais cela peut être annulé si nécessaire (ou si cela offense simplement la sensibilité de votre administrateur système).
La raison de ce comportement est d'empêcher plusieurs services de se déclencher exactement en même temps. Par exemple, vous pouvez utiliser des spécifications de temps telles que Hebdomadaire, Quotidien, etc. Ces raccourcis sont tous définis pour se déclencher à 00:00:00 heures le jour où ils sont déclenchés. Lorsque plusieurs minuteurs sont spécifiés de cette manière, il y a de fortes chances qu'ils tentent de démarrer simultanément.
Les temporisateurs systemd sont intentionnellement conçus pour se déclencher de manière quelque peu aléatoire autour de l'heure spécifiée pour essayer d'empêcher les déclenchements simultanés. Ils se déclenchent de manière semi-aléatoire dans une fenêtre de temps qui commence à l'heure de déclenchement spécifiée et se termine à l'heure spécifiée plus une minute. Ce temps de déclenchement est maintenu à une position stable par rapport à toutes les autres unités de temporisation définies, selon le systemd.timer page de manuel. Vous pouvez voir dans les entrées de journal ci-dessus que la minuterie s'est déclenchée immédiatement lorsqu'elle a démarré, puis environ 46 ou 47 secondes après chaque minute.
La plupart du temps, ces temps de déclenchement probabilistes conviennent. Lors de la planification de tâches telles que des sauvegardes à exécuter, tant qu'elles s'exécutent pendant les heures creuses, il n'y aura aucun problème. Un administrateur système peut sélectionner une heure de début déterministe, telle que 01:05:00 dans une spécification de tâche cron typique, pour ne pas entrer en conflit avec d'autres tâches, mais il existe une large plage de valeurs de temps qui permettront d'accomplir cela. Un peu d'aléatoire d'une minute dans une heure de début n'est généralement pas pertinent.
Cependant, pour certaines tâches, des temps de déclenchement exacts sont une exigence absolue. Pour ceux-ci, vous pouvez spécifier une plus grande précision de durée de déclenchement (à moins d'une microseconde) en ajoutant une déclaration comme celle-ci au Timer section du fichier d'unité de minuterie :
AccuracySec=1usLes intervalles de temps peuvent être utilisés pour spécifier la précision souhaitée ainsi que pour définir des intervalles de temps pour des événements répétés ou ponctuels. Il reconnaît les unités suivantes :
- usec, nous, µs
- ms, ms
- secondes, seconde, sec, s
- minutes, minutes, min, m
- heures, heure, h, h
- jours, jour, j
- semaines, semaine, w
- mois, mois, M (défini comme 30,44 jours)
- années, année, y (défini comme 365,25 jours)
Tous les minuteurs par défaut dans /usr/lib/systemd/system spécifiez une plage beaucoup plus large pour la précision car les temps exacts ne sont pas critiques. Examinez certaines des spécifications des minuteurs créés par le système :
[root@testvm1 system]# grep Accur /usr/lib/systemd/system/*timer
/usr/lib/systemd/system/fstrim.timer:AccuracySec=1h
/usr/lib/systemd/system/logrotate.timer:AccuracySec=1h
/usr/lib/systemd/system/logwatch.timer:AccuracySec=12h
/usr/lib/systemd/system/mlocate-updatedb.timer:AccuracySec=24h
/usr/lib/systemd/system/raid-check.timer:AccuracySec=24h
/usr/lib/systemd/system/unbound-anchor.timer:AccuracySec=24h
[root@testvm1 system]#
Afficher le contenu complet de certains des fichiers d'unité de minuterie dans /usr/lib/systemd/system répertoire pour voir comment ils sont construits.
Vous n'avez pas besoin d'activer le minuteur dans cette expérience pour l'activer au démarrage, mais la commande pour le faire serait :
# systemctl enable myMonitor.timerLes fichiers d'unité que vous avez créés n'ont pas besoin d'être exécutables. Vous n'avez pas non plus activé l'unité de service car elle est déclenchée par la minuterie. Vous pouvez toujours déclencher l'unité de service manuellement à partir de la ligne de commande, si vous le souhaitez. Essayez cela et observez le journal.
Voir les pages de manuel pour systemd.timer et systemd.time pour plus d'informations sur la précision de la minuterie, les spécifications d'heure d'événement et les événements déclencheurs.
Types de minuterie
Les temporisateurs systemd ont d'autres fonctionnalités qui ne se trouvent pas dans cron, qui ne se déclenchent qu'à des dates et heures spécifiques, répétitives et en temps réel. Les temporisateurs systemd peuvent être configurés pour se déclencher en fonction des changements d'état dans d'autres unités systemd. Par exemple, un minuteur peut être configuré pour déclencher un temps écoulé spécifique après le démarrage du système, après le démarrage ou après l'activation d'une unité de service définie. Ceux-ci sont appelés minuteries monotones. Monotone fait référence à un nombre ou à une séquence qui augmente continuellement. Ces minuteurs ne sont pas persistants car ils se réinitialisent après chaque démarrage.
Le tableau 1 répertorie les minuteurs monotones avec une courte définition de chacun, ainsi que le OnCalendar timer, qui n'est pas monotone et est utilisé pour spécifier des temps futurs qui peuvent ou non être répétitifs. Cette information est dérivée du systemd.timer page de manuel avec quelques modifications mineures.
| Minuterie | Monotone | Définition |
|---|---|---|
OnActiveSec= | X | Ceci définit une minuterie relative au moment où la minuterie est activée. |
OnBootSec= | X | Cela définit une minuterie relative au démarrage de la machine. |
OnStartupSec= | X | Ceci définit une minuterie relative au moment où le gestionnaire de services démarre pour la première fois. Pour les unités de minuterie système, ceci est très similaire à OnBootSec= , car le gestionnaire de services système démarre généralement très tôt au démarrage. Il est principalement utile lorsqu'il est configuré dans des unités exécutées dans le gestionnaire de services par utilisateur, car le gestionnaire de services utilisateur ne démarre généralement qu'à la première connexion, et non au démarrage. |
OnUnitActiveSec= | X | Ceci définit une minuterie relative au moment où la minuterie qui doit être activée a été activée pour la dernière fois. |
OnUnitInactiveSec= | X | Ceci définit une minuterie relative au moment où la minuterie qui doit être activée a été désactivée pour la dernière fois. |
OnCalendar= | Cela définit les minuteries en temps réel (c'est-à-dire l'horloge murale) avec des expressions d'événement de calendrier. Voir systemd.time(7) pour plus d'informations sur la syntaxe des expressions d'événement de calendrier. Sinon, la sémantique est similaire à OnActiveSec= et les paramètres associés. Ce minuteur est celui qui ressemble le plus à ceux utilisés avec le service cron. |
Tableau 1 :définitions des temporisateurs systemd
Les temporisateurs monotones peuvent utiliser les mêmes noms de raccourcis pour leurs durées que AccuracySec déclaration mentionnée précédemment, mais systemd normalise ces noms en secondes. Par exemple, vous pouvez spécifier une minuterie qui déclenche un événement une seule fois, cinq jours après le démarrage du système; qui pourrait ressembler à :OnBootSec=5d . Si l'hôte a démarré à 2020-06-15 09:45:27 , le minuteur se déclencherait à 2020-06-20 09:45:27 ou dans la minute qui suit.
Spécifications des événements d'agenda
Les spécifications des événements du calendrier sont un élément clé du déclenchement des minuteries aux heures répétitives souhaitées. Commencez par regarder quelques spécifications utilisées avec le OnCalendar réglage.
systemd et ses minuteries utilisent un style différent pour les spécifications d'heure et de date que le format utilisé dans crontab. Il est plus flexible que crontab et permet des dates et heures floues à la manière du at commande. Il doit également être suffisamment familier pour être facile à comprendre.
Le format de base pour les temporisateurs systemd utilisant OnCalendar= est DOW YYYY-MM-DD HH:MM:SS . DOW (jour de la semaine) est facultatif et d'autres champs peuvent utiliser un astérisque (*) pour correspondre à n'importe quelle valeur pour cette position. Tous les formulaires de temps calendaire sont convertis en un formulaire normalisé. Si l'heure n'est pas spécifiée, elle est supposée être 00:00:00. Si la date n'est pas spécifiée, mais que l'heure l'est, la prochaine correspondance peut avoir lieu aujourd'hui ou demain, selon l'heure actuelle. Des noms ou des numéros peuvent être utilisés pour le mois et le jour de la semaine. Des listes séparées par des virgules de chaque unité peuvent être spécifiées. Les plages d'unités peuvent être spécifiées avec .. entre les valeurs de début et de fin.
Il existe quelques options intéressantes pour spécifier les dates. Le tilde (~) peut être utilisé pour spécifier le dernier jour du mois ou un nombre spécifié de jours avant le dernier jour du mois. Le "/" peut être utilisé pour spécifier un jour de la semaine comme modificateur.
Voici quelques exemples de spécifications de temps typiques utilisées dans OnCalendar déclarations.
| Spécification d'événement d'agenda | Description |
|---|---|
| DOW AAAA-MM-JJ HH:MM:SS | |
| *-*-* 00:15:30 | Tous les jours de chaque mois de chaque année à 15 minutes et 30 secondes après minuit |
| Hebdomadaire | Tous les lundis à 00:00:00 |
| Lun *-*-* 00:00:00 | Comme hebdomadaire |
| Lun | Comme hebdomadaire |
| Mer 2020-*-* | Tous les mercredis de 2020 à 00:00:00 |
| Lun..Ven 2021-*-* | Tous les jours de la semaine en 2021 à 00:00:00 |
| 2022-6,7,8-1,15 01:15:00 | Les 1er et 15 juin, juillet et août 2022 à 01h15 |
| Lun *-05~03 | La prochaine occurrence d'un lundi de mai de n'importe quelle année qui est également le 3ème jour à partir de la fin du mois. |
| Lun..Ven *-08~04 | Le 4ème jour précédant la fin du mois d'août pour toutes les années où il tombe également un jour de semaine. |
| *-05~03/2 | Le 3ème jour à partir de la fin du mois de mai puis à nouveau deux jours plus tard. Se répète chaque année. Notez que cette expression utilise le tilde (~). |
| *-05-03/2 | Le troisième jour du mois de mai puis tous les 2 jours pendant le reste du mois de mai. Se répète chaque année. Notez que cette expression utilise le tiret (-). |
Table 2 :Exemple de OnCalendar spécifications de l'événement
Spécifications du calendrier de test
systemd fournit un excellent outil pour valider et examiner les spécifications d'événements de temps calendaire dans une minuterie. Le calendrier systemd-analyze calendar L'outil analyse une spécification d'événement de temps calendaire et fournit la forme normalisée ainsi que d'autres informations intéressantes telles que la date et l'heure du prochain "écoulement", c'est-à-dire la correspondance, et le temps approximatif avant que l'heure de déclenchement ne soit atteinte.
Tout d'abord, regardez une date dans le futur sans heure (notez que les heures pour Next elapse et UTC différera en fonction de votre fuseau horaire local) :
[student@studentvm1 ~]$ systemd-analyze calendar 2030-06-17
Original form: 2030-06-17
Normalized form: 2030-06-17 00:00:00
Next elapse: Mon 2030-06-17 00:00:00 EDT
(in UTC): Mon 2030-06-17 04:00:00 UTC
From now: 10 years 0 months left
[root@testvm1 system]#
Now add a time. In this example, the date and time are analyzed separately as non-related entities:
[root@testvm1 system]# systemd-analyze calendar 2030-06-17 15:21:16
Original form: 2030-06-17
Normalized form: 2030-06-17 00:00:00
Next elapse: Mon 2030-06-17 00:00:00 EDT
(in UTC): Mon 2030-06-17 04:00:00 UTC
From now: 10 years 0 months left
Original form: 15:21:16
Normalized form: *-*-* 15:21:16
Next elapse: Mon 2020-06-15 15:21:16 EDT
(in UTC): Mon 2020-06-15 19:21:16 UTC
From now: 3h 55min left
[root@testvm1 system]#
To analyze the date and time as a single unit, enclose them together in quotes. Be sure to remove the quotes when using them in the OnCalendar= event specification in a timer unit or you will get errors:
[root@testvm1 system]# systemd-analyze calendar "2030-06-17 15:21:16"
Normalized form: 2030-06-17 15:21:16
Next elapse: Mon 2030-06-17 15:21:16 EDT
(in UTC): Mon 2030-06-17 19:21:16 UTC
From now: 10 years 0 months left
[root@testvm1 system]#
Now test the entries in Table 2. I like the last one, especially:
[root@testvm1 system]# systemd-analyze calendar "2022-6,7,8-1,15 01:15:00"
Original form: 2022-6,7,8-1,15 01:15:00
Normalized form: 2022-06,07,08-01,15 01:15:00
Next elapse: Wed 2022-06-01 01:15:00 EDT
(in UTC): Wed 2022-06-01 05:15:00 UTC
From now: 1 years 11 months left
[root@testvm1 system]#
Let’s look at one example in which we list the next five elapses for the timestamp expression.
[root@testvm1 ~]# systemd-analyze calendar --iterations=5 "Mon *-05~3"
Original form: Mon *-05~3
Normalized form: Mon *-05~03 00:00:00
Next elapse: Mon 2023-05-29 00:00:00 EDT
(in UTC): Mon 2023-05-29 04:00:00 UTC
From now: 2 years 11 months left
Iter. #2: Mon 2028-05-29 00:00:00 EDT
(in UTC): Mon 2028-05-29 04:00:00 UTC
From now: 7 years 11 months left
Iter. #3: Mon 2034-05-29 00:00:00 EDT
(in UTC): Mon 2034-05-29 04:00:00 UTC
From now: 13 years 11 months left
Iter. #4: Mon 2045-05-29 00:00:00 EDT
(in UTC): Mon 2045-05-29 04:00:00 UTC
From now: 24 years 11 months left
Iter. #5: Mon 2051-05-29 00:00:00 EDT
(in UTC): Mon 2051-05-29 04:00:00 UTC
From now: 30 years 11 months left
[root@testvm1 ~]#
This should give you enough information to start testing your OnCalendar time specifications. The systemd-analyze calendar tool can be used for other interesting analyses, which I will begin to explore in the next article in this series.
Summary
systemd timers can be used to perform the same kinds of tasks as the cron tool but offer more flexibility in terms of the calendar and monotonic time specifications for triggering events.
Even though the service unit you created for this experiment is usually triggered by the timer, you can also use the systemctl start myMonitor.service command to trigger it at any time. Multiple maintenance tasks can be scripted in a single timer; these can be Bash scripts or Linux utility programs. You can run the service triggered by the timer to run all the scripts, or you can run individual scripts as needed.
I will explore systemd's use of time and time specifications in much more detail in the next article.
I have not yet seen any indication that cron and at will be deprecated. I hope that does not happen because at , at least, is much easier to use for one-off task scheduling than systemd timers.
Resources
There is a great deal of information about systemd available on the internet, but much is terse, obtuse, or even misleading. In addition to the resources mentioned in this article, the following webpages offer more detailed and reliable information about systemd startup.
- The Fedora Project has a good, practical guide to systemd. It has pretty much everything you need to know in order to configure, manage, and maintain a Fedora computer using systemd.
- The Fedora Project also has a good cheat sheet that cross-references the old SystemV commands to comparable systemd ones.
- For detailed technical information about systemd and the reasons for creating it, check out Freedesktop.org's description of systemd.
- Linux.com's "More systemd fun" offers more advanced systemd information and tips.
There is also a series of deeply technical articles for Linux sysadmins by Lennart Poettering, the designer and primary developer of systemd. These articles were written between April 2010 and September 2011, but they are just as relevant now as they were then. Much of everything else good that has been written about systemd and its ecosystem is based on these papers.
- Rethinking PID 1
- systemd for Administrators, Part I
- systemd for Administrators, Part II
- systemd for Administrators, Part III
- systemd for Administrators, Part IV
- systemd for Administrators, Part V
- systemd for Administrators, Part VI
- systemd for Administrators, Part VII
- systemd for Administrators, Part VIII
- systemd for Administrators, Part IX
- systemd for Administrators, Part X
- systemd for Administrators, Part XI