Clever Geek Handbook

Utilisation des minuteries systemd au lieu des tĂąches cron

Je suis actuellement en train de remplacer mes tùches cron par des minuteries systemd. J'utilise des minuteries depuis plusieurs années, mais en général, je n'approfondissais pas les subtilités de leur utilisation, ne déterminant que ce qui était nécessaire pour accomplir la tùche qui m'intéressait. J'ai récemment travaillé sur une série d'articles sur systemd et j'ai découvert que les minuteries systemd avaient des fonctionnalités trÚs intéressantes.







Ces minuteries, comme les tĂąches cron, peuvent, Ă  un moment donnĂ©, dĂ©clencher diverses actions sur le systĂšme. Par exemple - exĂ©cuter des scripts ou des programmes shell. Les minuteries peuvent fonctionner, par exemple, une fois par jour et uniquement le lundi. Un autre exemple est une minuterie qui se dĂ©clenche toutes les 15 minutes pendant les heures de bureau (de 8 h Ă  18 h). Mais les minuteries systemd peuvent faire quelque chose que les tĂąches cron ne peuvent pas faire. Par exemple, un minuteur peut appeler un script ou un programme une heure spĂ©cifiĂ©e aprĂšs un Ă©vĂ©nement. Un tel Ă©vĂ©nement peut ĂȘtre le dĂ©marrage du systĂšme ou le dĂ©marrage de systemd, l'achĂšvement d'une tĂąche prĂ©cĂ©dente ou mĂȘme la fin d'un service prĂ©cĂ©demment appelĂ© par un minuteur.



Minuteries utilisées pour la maintenance du systÚme



Lorsque Fedora ou une autre distribution Linux basée sur systemd est installée sur un ordinateur, plusieurs minuteries sont créées dans le cadre des routines de maintenance du systÚme. Ces procédures sont automatiquement exécutées sur n'importe quel systÚme Linux. Les minuteries correspondantes déclenchent diverses tùches de service, telles que la mise à jour des bases de données systÚme, la suppression des répertoires temporaires, la rotation des fichiers journaux, etc.



A titre d'exemple, je vais donner ici des informations sur les minuteries disponibles sur la machine virtuelle que j'ai utilisĂ©e pour les expĂ©riences. Ici, pour obtenir une liste de tous les minuteurs, j'ai utilisĂ© la commandesystemctl status *timer... Le caractĂšre gĂ©nĂ©rique astĂ©risque joue ici le mĂȘme rĂŽle que dans d'autres commandes similaires. À savoir, cela indique au systĂšme que nous nous intĂ©ressons Ă  tous les minuteries (unitĂ©s de minuterie, elles sont Ă©galement appelĂ©es "fichiers d'unitĂ© de minuterie" ou "unitĂ©s de minuterie") de 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 timer est associé à au moins six lignes contenant des informations à son sujet:



  • La premiĂšre ligne contient le nom du fichier du minuteur et une brĂšve description du but de l'existence du minuteur.
  • La deuxiĂšme ligne affiche des informations sur l'Ă©tat de la minuterie. À savoir, il indique s'il est chargĂ©, donne le chemin complet vers le fichier du minuteur, montre l'Ă©tat du prĂ©rĂ©glage du fournisseur (dĂ©sactivĂ© ou activĂ©).
  • La troisiĂšme ligne affiche des informations sur l'activitĂ© de la minuterie, qui comprend des informations sur le moment oĂč la minuterie a Ă©tĂ© activĂ©e.
  • La quatriĂšme ligne contient la date et l'heure du prochain dĂ©marrage de la minuterie et le temps approximatif restant jusqu'Ă  ce qu'il dĂ©marre.
  • La cinquiĂšme ligne donne le nom du service ou de l'Ă©vĂ©nement appelĂ© par le temporisateur.
  • Certains fichiers d'unitĂ© de minuterie systemd (mais pas tous) contiennent des pointeurs vers la documentation. Ces pointeurs sont, dans mon exemple, dans les descriptions de trois minuteries.
  • La derniĂšre ligne de la description du temporisateur est l'entrĂ©e de journal associĂ©e Ă  l'instance la plus rĂ©cente du service appelĂ© par le temporisateur.


Si vous essayez d'exécuter une commande sur votre ordinateur systemctl status *timer, le jeu de minuteries qui lui est présenté peut trÚs bien différer du mien.



Création de minuterie



Bien que nous puissions comprendre les spécificités du fonctionnement des minuteries en analysant les minuteries existantes, je suggÚre de créer votre propre fichier d'unité de service (fichier de configuration de service, unité de service ) et un fichier de minuterie avec lequel le service correspondant sera appelé. Nous sommes ici, pour ne pas compliquer l'histoire, donner un exemple assez trivial. Mais aprÚs l'avoir traité, il vous sera plus facile de comprendre le travail des autres chronométreurs.



Tout d'abord, crĂ©ons un fichier de configuration de service simple qui exĂ©cutera quelque chose d'aussi simple qu'une commande free. Par exemple, cela peut ĂȘtre nĂ©cessaire si nous avons besoin de surveiller rĂ©guliĂšrement la quantitĂ© de mĂ©moire disponible. CrĂ©ons un fichier unitĂ© nommĂ© myMonitor.servicedans le dossier /etc/systemd/system. Il n'est pas nĂ©cessaire qu'il soit 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


Ce fichier est probablement le fichier de configuration de service le plus simple. Maintenant, vérifions son état et testons-le pour nous assurer qu'il 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]#


Pourquoi rien n'est sorti sur la console? Cela est dĂ» au fait que, par dĂ©faut, la sortie standard ( stdout) des programmes dĂ©marrĂ©s par systemd Ă  l'aide de fichiers d'unitĂ© de service est redirigĂ©e vers le journal systemd. Pour cette raison, au moins tant que les enregistrements correspondants existent, ces enregistrements peuvent ĂȘtre analysĂ©s. Jetons un coup d'Ɠil dans le journal et cherchons les entrĂ©es liĂ©es Ă  notre service et au jour oĂč nous avons testĂ©. La commande correspondante ressemblera Ă  ceci : journalctl -S today -u myMonitor.service. La clĂ© -Sest une version abrĂ©gĂ©e --since. Il vous permet de spĂ©cifier la pĂ©riode pendant laquelle l'utilitairejournalctlĂ  la recherche de disques. Le fait n'est pas que nous ne sommes pas intĂ©ressĂ©s par les rĂ©sultats antĂ©rieurs. Dans notre cas, de tels rĂ©sultats ne seront tout simplement pas. Cette clĂ© est utilisĂ©e pour rĂ©duire le temps dont l'utilitaire a besoin pour rechercher des donnĂ©es. Si l'ordinateur fonctionne depuis longtemps, de nombreuses entrĂ©es peuvent s'accumuler dans le journal. 



[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 lancĂ©e Ă  l'aide d'un fichier de configuration de service peut ĂȘtre reprĂ©sentĂ©e comme un programme unique, une sĂ©quence de programmes ou un script Ă©crit dans n'importe quel langage de script. Ajoutons myMonitor.serviceune autre tĂąche au fichier unitĂ© , y compris les [Service]suivantes Ă  la fin de la section : 



ExecStart=/usr/bin/lsblk


RedĂ©marrons le service et vĂ©rifions le journal. Il devrait y avoir quelque chose qui ressemble Ă  ce qui est montrĂ© ci-dessous. À savoir, le journal doit contenir les donnĂ©es gĂ©nĂ©rĂ©es par les deux commandes: 



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, une fois que nous sommes sûrs que tout fonctionne correctement, nous allons créer, dans le dossier /etc/systemd/system, un fichier d'unité de minuterie, en lui donnant un nom myMonitor.timer. Ajoutez ce qui suit au fichier: 



# 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


L'horodatage OnCalendardans ce fichier ,, *-*-* *:*:00devrait amener le minuteur à appeler l'unité myMonitor.servicetoutes les minutes. OnCalendarNous en parlerons plus en détail ci-dessous.



En attendant, nous pouvons jeter un Ɠil aux entrĂ©es de journal liĂ©es au dĂ©marrage du service de minuterie. Nous pouvons Ă©galement activer le mode montre minuterie. Cependant, la surveillance du service vous permettra de voir les rĂ©sultats en temps quasi rĂ©el. Pour ce faire, vous devez exĂ©cuter journalctlavec la touche -f( follow): 



[root@testvm1 system]# journalctl -S today -f -u myMonitor.service
-- Logs begin at Mon 2020-06-08 07:47:20 EDT. --


DĂ©marrez le minuteur, mais ne l'incluez pas dans le dĂ©marrage automatique au dĂ©marrage du systĂšme.  



[root@testvm1 ~]# systemctl start myMonitor.timer
[root@testvm1 ~]#


Regardez ce qui se passe pendant un moment.



L'un des résultats apparaßt immédiatement. Et les suivants seront affichés à des intervalles d'environ une minute. Regardez le magazine pendant quelques minutes. 



[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 à la fois l'état de la minuterie et l'état du service.



Avez-vous rĂ©ussi Ă  remarquer ici ce que j'ai remarquĂ©? Vous avez peut-ĂȘtre remarquĂ© au moins deux choses en lisant le magazine.



PremiÚrement - le fait que vous n'avez pas besoin de faire quelque chose de spécial pour vous connecter à celui ExecStartd' myMonitor.serviceécrire stdout. Cette fonction fait partie des fonctions de démarrage standard de systemd. Mais cela signifie que vous devrez probablement faire attention lors de l'exécution de scripts à partir de fichiers de configuration de service, en notant la quantité de données dans laquelle ils écrivent stdout.



DeuxiĂšmement, vous avez peut-ĂȘtre remarquĂ© que la minuterie ne dĂ©marre pas exactement Ă :00secondes de chaque minute, et mĂȘme pas exactement une minute aprĂšs la derniĂšre exĂ©cution. C'est l'une des caractĂ©ristiques de ces minuteries, si cela est nĂ©cessaire (ou si cela blesse les sentiments de l'administrateur systĂšme), ce comportement des minuteries peut ĂȘtre modifiĂ© en les rendant plus prĂ©cis.



La raison pour laquelle la minuterie ne dĂ©marre pas en :00secondes de chaque minute est que le systĂšme a donc tendance Ă  empĂȘcher plusieurs services de dĂ©marrer simultanĂ©ment. Par exemple, lors de la configuration de l'indicateur de temps, OnCalendarvous pouvez utiliser des valeurs telles que Weekly, Dailyet autres. Ces mĂ©thodes abrĂ©gĂ©es de dĂ©nomination des points dans le temps sont configurĂ©es de sorte que les minuteries dans lesquelles elles sont utilisĂ©es commencent Ă 00:00:00le jour correspondant. Lorsque plusieurs minuteries sont configurĂ©es de cette façon, il y a de fortes chances qu'elles se dĂ©clenchent toutes en mĂȘme temps.



C'est pourquoi les minuteries systemd sont dĂ©libĂ©rĂ©ment conçues de maniĂšre Ă  ne pas dĂ©marrer exactement Ă  l'heure spĂ©cifiĂ©e, mais avec un Ă©cart alĂ©atoire par rapport Ă  celle-ci. Cette dĂ©viation ne peut pas ĂȘtre qualifiĂ©e de complĂštement accidentelle. Les minuteries commencent quelque part dans une fenĂȘtre de temps qui commence au moment spĂ©cifiĂ© et se termine Ă  une minute de l'original. Cette heure, conformĂ©ment Ă  la documentation de systemd.timer, est maintenue dans un Ă©tat stable, en tenant compte de tous les autres temporisateurs dĂ©clarĂ©s dans le systĂšme. Dans le fragment de journal ci-dessus, vous pouvez voir que le minuteur est dĂ©clenchĂ© immĂ©diatement aprĂšs son dĂ©marrage, puis - environ 46 ou 47 secondes aprĂšs le dĂ©but de chaque minute suivante.



Le plus souvent, une telle approche probabiliste pour déterminer le moment exact des minuteries convient à tout le monde. Lors de la planification de tùches telles que la création d'une copie de sauvegarde de quelque chose tant que ces tùches sont effectuées en dehors des heures de bureau, cela ne pose aucun problÚme. L'administrateur systÚme, qui configure les tùches cron, peut spécifier des heures clairement définies pour les démarrer, par exemple 01:05:00essayer de s'assurer que ces tùches n'entrent pas en conflit avec d'autres. Il existe un large éventail de façons de spécifier le temps qui le permet. Les changements aléatoires de l'heure de début d'une tùche qui ne dépassent pas une minute ne jouent généralement pas un rÎle particulier.



Mais pour certaines tĂąches, le moment exact du chronomĂštre est extrĂȘmement important. Dans de tels cas, lors du rĂ©glage des minuteries, vous pouvez spĂ©cifier une heure plus prĂ©cise de leur fonctionnement (jusqu'Ă  la prĂ©cision, mesurĂ©e en microsecondes). Cela se fait en ajoutant au fichier de description du minuteur, dans la section Timer, une construction qui ressemble Ă  ce qui suit: 



AccuracySec=1us


Vous pouvez utiliser des mots clĂ©s spĂ©ciaux pour spĂ©cifier la prĂ©cision souhaitĂ©e du minuteur. Ces mots clĂ©s peuvent Ă©galement ĂȘtre utilisĂ©s lors de la configuration d'Ă©vĂ©nements rĂ©currents et ponctuels. Le systĂšme comprend les mots-clĂ©s suivants:



  • Microseconde: usec, us, ”s.
  • Milliseconde: msec, ms.
  • DeuxiĂšmement: seconds, second, sec, s.
  • Minute: minutes, minute, min, m.
  • Heure: hours, hour, hr, h.
  • Jour: days, day, d.
  • Semaine: weeks, week, w.
  • Mois: months, month, M(le mois est dĂ©fini comme 30,44 jours).
  • AnnĂ©e: years, year, y(l'annĂ©e est dĂ©finie comme 365,25 jours).


Tous les minuteries standard disponibles dans /usr/lib/systemd/systemsont configurĂ©es en utilisant des plages beaucoup plus longues qui dĂ©finissent la prĂ©cision de leur dĂ©clenchement, car dans le cas de ces minuteries, leur dĂ©clenchement Ă  une heure strictement spĂ©cifiĂ©e n'est pas particuliĂšrement importante. Jetez un Ɠil aux spĂ©cifications de certains des minuteries gĂ©nĂ©rĂ©es 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]#


Pour mieux comprendre la structure interne des fichiers de minuterie à partir du répertoire /usr/lib/systemd/system, vous pouvez afficher leur contenu.



Vous n'avez pas besoin de configurer notre minuterie d'apprentissage pour qu'elle s'active au démarrage de votre systÚme. Cependant, si vous le souhaitez, vous pouvez utiliser la commande suivante pour cela: 



[root@testvm1 system]# systemctl enable myMonitor.timer


Les fichiers de minuterie que vous allez crĂ©er n'ont pas besoin d'ĂȘtre exĂ©cutables. De plus, les fichiers de configuration de service n'ont pas besoin d'ĂȘtre configurĂ©s pour ĂȘtre activĂ©s au dĂ©marrage, car ils sont appelĂ©s par des minuteries. Si nĂ©cessaire, le service peut Ă©galement ĂȘtre appelĂ© manuellement Ă  partir de la ligne de commande. Essayez ceci et regardez dans le journal systemd.



Pour en savoir plus sur la précision des minuteries, comment spécifier l'heure de déclenchement des événements et comment déclencher des événements, consultez la documentation de systemd.timeret systemd.time.



Types de minuterie



Les minuteries Systemd ont d'autres fonctionnalitĂ©s que les tĂąches cron n'ont pas, «ponctuelles» ou rĂ©pĂ©titives, qui ne sont appelĂ©es qu'avec des dates en temps rĂ©el et en temps rĂ©el. Les minuteries Systemd peuvent ĂȘtre configurĂ©es pour ĂȘtre appelĂ©es en fonction des changements d'Ă©tat d'autres unitĂ©s systemd. Par exemple, le minuteur peut ĂȘtre configurĂ© de sorte qu'il soit dĂ©clenchĂ© aprĂšs un temps spĂ©cifiĂ© aprĂšs le dĂ©marrage du systĂšme, aprĂšs que l'utilisateur s'y soit connectĂ©, ou aprĂšs un temps spĂ©cifiĂ© aprĂšs l'activation d'un certain service. Ces minuteries sont appelĂ©es monotones. Ces minuteries sont rĂ©initialisĂ©es aprĂšs chaque redĂ©marrage du systĂšme.



Le tableau suivant prĂ©sente une liste de minuteries monotones avec une brĂšve description de chacun d'eux. Il existe Ă©galement une description de la minuterie.OnCalendar, qui n'est pas monotone et est utilisĂ© dans les cas oĂč vous devez organiser un lancement unique ou rĂ©pĂ©tĂ© de quelque chose dans le futur. Ce tableau est basĂ© sur la documentation systemd.timer.

Minuteur Monotone La description 
OnActiveSec=


X Le temps de fonctionnement de la minuterie est réglé par rapport au moment de l'activation de la minuterie. 
OnBootSec=


X Le minuteur est rĂ©glĂ© en fonction du moment oĂč le systĂšme dĂ©marre. 
OnStartupSec=


X . OnBootSec=, . , , , , , . 
OnUnitActiveSec=


X , , , . 
OnUnitInactiveSec=


X , , , . 
OnCalendar=


  . systemd.time(7). OnActiveSec=. — systemd, , cron.


Lors de la configuration de minuteries monotones, les mĂȘmes mots-clĂ©s peuvent ĂȘtre utilisĂ©s comme dĂ©crit ci-dessus en parlant de AccuracySec. Mais il convient de noter que systemd convertit les intervalles de temps correspondants en secondes. Par exemple, vous pouvez dĂ©finir une minuterie qui se dĂ©clenche une fois, cinq jours aprĂšs le dĂ©marrage du systĂšme. Il peut ressembler Ă  une description comme ceci: OnBootSec=5d. Si l'ordinateur a Ă©tĂ© dĂ©marrĂ© 2020-06-15Ă  09:45:27, le minuteur dĂ©marre 2020-06-20Ă  09:45:27(ou dans la minute qui suit ce moment).



Description des événements du calendrier



L'application d'événements de calendrier est un élément clé de la description des minuteries appelées à intervalles réguliers. Analysons certaines des caractéristiques de ces événements utilisées lors du réglage de l'indicateur de temps OnCalendar.



Systemd et ses minuteries correspondantes utilisent un format d'heure et de date diffĂ©rent de celui de crontab. Ce format est plus flexible que celui utilisĂ© dans crontab. Il vous permet de spĂ©cifier la date et l'heure de maniĂšre simplifiĂ©e, dans le style de commande at. Pour ceux qui le connaissent at, il devrait ĂȘtre facile de comprendre les paramĂštres de la minuterie systemd.



Lorsqu'il est utilisé OnCalendar=pour configurer des minuteries, le format de base suivant est utilisé pour spécifier la date et l'heure: 



DOW YYYY-MM-DD HH:MM:SS


DOW(Day Of Week), il s'agit d'une partie facultative de la construction ci-dessus. Dans d'autres champs, vous pouvez utiliser le symbole astĂ©risque ( *) pour reprĂ©senter toute valeur qui peut apparaĂźtre dans la position qu'elle occupe. Toutes les formes d'indication de la date et de l'heure sont converties en forme normalisĂ©e. Si aucune heure n'est spĂ©cifiĂ©e, elle est supposĂ©e ĂȘtre 00:00:00. Si la date n'est pas spĂ©cifiĂ©e, mais que l'heure est spĂ©cifiĂ©e, le minuteur fonctionnera soit le jour de son dĂ©marrage (relativement parlant, «aujourd'hui»), soit le jour suivant («demain»). Cela dĂ©pend de l'heure actuelle. Les mois et les jours de la semaine peuvent ĂȘtre nommĂ©s en utilisant leurs noms. Vous pouvez utiliser ici des listes de valeurs sĂ©parĂ©es par des virgules. Les plages de valeurs peuvent ĂȘtre sĂ©parĂ©es par trois points ( 
), qui apparaissent entre la valeur de dĂ©but et de fin de la plage.



Lors de la spĂ©cification des dates, nous avons quelques options intĂ©ressantes Ă  notre disposition. Ainsi, un tilde (~) peut ĂȘtre utilisĂ© pour indiquer le dernier jour d'un mois, ou pour indiquer une date un nombre donnĂ© de jours avant le dernier jour du mois. La barre oblique (/) peut ĂȘtre utilisĂ©e comme modificateur pour indiquer le jour de la semaine.



Le tableau suivant montre quelques exemples typiques de minutage utilisé dans une expression OnCalendar.



Exemple de prĂ©sentation d'un Ă©vĂ©nement du calendrier DOW YYYY-MM-DD HH:MM:SS

La description 
*-*-* 00:15:30


Tous les jours de chaque mois de chaque année, 15 minutes 30 secondes aprÚs minuit. 
Weekly


Tous les lundis Ă  00:00:00. 
Mon *-*-* 00:00:00


Le mĂȘme que Weekly. 
Mon


Le mĂȘme que Weekly. 
Wed 2020-*-*


Tous les mercredis 2020 Ă  00:00:00. 
Mon..Fri 2021-*-*


Tous les jours de la semaine en 2021 Ă  00:00:00. 
2022-6,7,8-1,15 01:15:00


1er et 15 juin, juillet et août 2022 01:15:00aprÚs minuit. 
Mon *-05~03


, , , 3 . 
Mon..Fri *-08~04


, 4 , . 
*-05~03/2


3 , , — , . . , ~. 
*-05-03/2


, — . . , (-).


,



Systemd a un excellent outil pour vérifier et examiner les spécifications des événements du calendrier. Il s'agit d'une équipe systemd-analyze calendarqui analyse les descriptions des événements du calendrier et les présente sous une forme normalisée. Cette commande fournit également d'autres informations intéressantes, telles que la date et l'heure du prochain événement de ce type, et le temps approximatif restant jusqu'à ce moment.



Tout d'abord, regardons la spécification, qui contient uniquement la date, ne contient pas d'informations sur l'heure (notez que les heures dans les champs Next elapseet (in UTC)sont différentes, cette différence dépend du 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]#


Ajoutons maintenant des informations de temps à la description. Dans cet exemple, la date et l'heure sont analysées séparément, en tant qu'entités qui ne sont pas liées les unes aux autres: 



[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]#


Prenons maintenant un exemple oĂč la date et l'heure sont considĂ©rĂ©es ensemble. Pour ce faire, ils doivent ĂȘtre placĂ©s entre guillemets. Mais si vous utilisez une telle construction dans OnCalendar, n'oubliez pas de supprimer les guillemets, sinon vous rencontrerez des erreurs: 



[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]#


Maintenant, vérifions quelque chose du tableau précédent. J'aime particuliÚrement cette description d'elle: 



2022-6,7,8-1,15 01:15:00


Analysons-le: 



[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]#


Jetons maintenant un Ɠil à la description Mon *-05~3, mais cette fois, nous demanderons au programme des informations sur les 5 prochaines fois de la minuterie, qui utilise les paramùtres suivants: 



[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 ~]#


Je pense que nous avons couvert suffisamment de cas d'utilisation systemd-analyze calendarpour vous permettre de tester vos propres descriptions d'événements de calendrier. Gardez à l'esprit que l'outil systemd-analyzea d'autres fonctionnalités intéressantes.



Matériaux additionnels



Il existe de nombreuses publications sur systemd sur Internet, mais elles sont pour la plupart trop courtes, trĂšs simplistes, voire boguĂ©es. Cet article fournit de bonnes sources d'informations sur systemd. Vous trouverez ci-dessous une liste de liens vers d'autres documents de qualitĂ© sur ce sujet. 



  • Un guide pratique de systemd par le projet Fedora.
  • Une feuille de triche du projet Fedora qui mappe les commandes SystemV et systemd hĂ©ritĂ©es.
  • DĂ©tails sur systemd et pourquoi il a Ă©tĂ© crĂ©Ă©.
  • MatĂ©riel avec informations et conseils, dĂ©diĂ© Ă  systemd.
  • (Lennart Poettering), systemd. , 2010 2011, . systemd .
  • systemd.
  • systemd.




Les minuteries Systemd peuvent ĂȘtre utilisĂ©es pour accomplir les mĂȘmes tĂąches que les tĂąches cron. Mais systemd vous offre plus de flexibilitĂ© en termes de configuration du calendrier et des minuteries monotones.



MĂȘme si les fichiers de configuration de service que nous crĂ©ons lors de nos expĂ©riences sont gĂ©nĂ©ralement appelĂ©s Ă  l'aide de minuteries, vous pouvez les appeler Ă  tout moment en utilisant une commande comme systemctl start myMonitor.service. Une minuterie peut dĂ©marrer plusieurs tĂąches. Cela peut ĂȘtre, par exemple, des scripts Bash et des utilitaires Linux. Un fichier de configuration de service peut ĂȘtre composĂ© de sorte que lorsqu'il est appelĂ©, plusieurs scripts sont exĂ©cutĂ©s. Vous pouvez Ă©galement exĂ©cuter les scripts sĂ©parĂ©ment.



Si nous parlons de la coexistence de systemd, cron et at, alors je tiens Ă  noter que je n'ai encore vu aucun signe que cron ou at serait obsolĂšte. J'espĂšre qu'ils continueront Ă  ĂȘtre pris en charge, car at est au moins beaucoup plus facile que systemd Ă  utiliser pour planifier des tĂąches ponctuelles.



Qu'est-ce que vous utilisez? Minuteries Systemd ou tĂąches cron?





More articles:


All Articles