systemd/cron

De ArchwikiFR
Révision datée du 16 juillet 2014 à 23:06 par Benjarobin (discussion | contributions) (Timer relatif à un point de départ : Correction faute...)

systemd est capable de réaliser une partie des fonctionnalités de cron depuis la version 197 et d'anacron à l'aide des options Persistent et OnCalendar.


Unités Timer

Ces fichiers sont des unités systemd qui se terminent en .timer. Ce type de fichier suit les mêmes règles que les fichiers de configuration pour les unités.

La configuration spécifique d'un timer se trouve dans la partie [Timer]. Il y a deux manières de définir quand le service sera activé:

  • le temps est relatif à un point de départ. Les points de départ les plus courants sont le démarrage de la machine, en utilisant l'option OnBootSec ainsi que le moment ou le timer a été activé, dans ce cas il faut utiliser OnUnitActiveSec.
  • le temps relatif au temps réel, en utilisant l'option OnCalendar.

Il faut donc choisir l'option qui correspond à vos besoins, cela dépend donc si vous voulez démarrer le service après chaque démarrage ou non.

Pour chaque fichier .timer, un service doit exister pour décrire l'unité à activer quand le timer s'active. Par défaut, un service portant le même nom que le timer (à l'exception du suffixe) sera active. Un exemple basique serait de créer un foo.timer pour activer un foo.service.

Comme le service est démarré par l'unité timer, il n'est pas nécessaire d'écrire une section [Install] dans le service correspondant. Vous ne devez pas activer le service, mais le timer qui activera le service. Par contre les unités timer ont besoin d'une section [Install] et doivent être activé par un timers.target.

Consulter systemd.timer(5) pour une liste complète de toutes les options disponibles pour l'unité timer.

Pour consulter tous les timer actifs avec les détails, exécutez la commande suivante:

$ systemctl list-timers
NEXT                          LEFT        LAST                          PASSED     UNIT                         ACTIVATES
Thu 2014-07-10 19:37:03 CEST  11h left    Wed 2014-07-09 19:37:03 CEST  12h ago    systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Fri 2014-07-11 00:00:00 CEST  15h left    Thu 2014-07-10 00:00:13 CEST  8h ago     logrotate.timer              logrotate.service

Exemple basique

Timer relatif à un point de départ

Supposons que vous vouliez démarrer un script de backup myBackup.service une fois par semaine et ce service doit être démarré après chaque démarrage. Il faut tout d'abord écrire le service suivant:

Fichier: /etc/systemd/system/myBackup.service
 
 [Unit]
 Description=run a backup 
 
 [Service]
 Nice=19
 IOSchedulingClass=2
 IOSchedulingPriority=7 
 ExecStart=/path/to/service/myBackup

ansi que l'unité correspondante:

Fichier: /etc/systemd/system/myBackup.timer
[Unit]
Description=run backup once in a week and after reboot

[Timer]
OnBootSec=15min      # service will start 15 minutes after you boot
OnUnitActiveSec=1w   # service will start every week after the timer was last activated

[Install]
WantedBy=timers.target

Il faut ensuite activer et démarrer le timer. Cela créera un lien symbolique vers /etc/systemd/system/timers.target.wants/myBackup.timer. Pour s'assurer que vos nouveaux timer et services sont activés:

$ systemctl status myBackup
● myBackup.service - run a backup 
   Loaded: loaded (/etc/systemd/system/myBackup.service; static)
   Active: inactive (dead) since Wed 2014-07-09 10:27:45 CEST; 1h 8min ago
 Main PID: 22000 (code=exited, status=0/SUCCESS)
$ systemctl status myBackup.timer
● myBackup.timer - run backup once in a week and after reboot
   Loaded: loaded (/etc/systemd/system/myBackup.timer; enabled)
   Active: active (waiting) since Mon 2014-07-07 19:21:53 CEST; 1 day 16h ago
Note :
  • Ce service est marqué inactif étant donné qu'il ne doit pas rester actif une fois que la sauvegarde a été effectuée. Ainsi il n'est pas nécessaire d'utiliser l'option RemainAfterExit=yes dans l'unité correspondante.
  • Le timer est indiqué en attente, car il attend la prochaine activation.
  • Dans le cas où le service est gourmand en ressource, il est conseillé de démarrer le timer suffisament de temps après le démarrage de la machine. Sinon le login et le démarrage de X peuvent être sérieusement ralentis.