systemd (Français)/Timers (Français)

État de la traduction: Cet article est la version francophone de systemd/Timers. Date de la dernière traduction: 2022-01-11. Vous pouvez aider à synchroniser la traduction s'il y a eu des changements dans la version anglaise.

Related articles

• systemd (Français)
• systemd (Français)/User (Français)
• systemd FAQ
• Cron (Français)

Les «timers» (minuteurs) sont des fichiers d'unité systemd dont le nom se termine par .timer et qui contrôlent des fichiers ou des événements .service. Les timers peuvent être utilisés comme une alternative à cron. (lire #En tant que remplacement de cron). Les timers prennent en charge par défaut les événements du calendrier, les événements monotones, et peuvent être exécutés de manière asynchrone.

Unités timer

Les «timers» sont des fichiers d'unités systemd avec un suffixe .timer. Les timers sont comme les autres fichiers de configuration d'unité et sont chargés à partir des mêmes chemins mais incluent une section [Timer] qui définit quand et comment le timer s'active. Les timers sont définis comme l'un des deux types suivants :

• Les timers en temps réel (aussi appelés timers d'«horloge murale») sont activés par un événement du calendrier, de la même manière que les tâches de cron. L'option OnCalendar= est utilisée pour les définir.
• Les timers monotoniques s'activent après un laps de temps relatif à un point de départ variable. Ils s'arrêtent si l'ordinateur est temporairement suspendu ou éteint. Il existe un certain nombre de timers monotones différents mais tous ont la forme suivante : OnTypeSec=. Les timers monotones courants comprennent OnBootSec et OnUnitActiveSec.

Pour une explication complète des options des timers, consultez systemd.timer(5). La syntaxe des arguments pour les événements du calendrier et les intervalles de temps est définie dans systemd.time(7).

Note: systemd offre la cible timers.target qui configure tous les timers qui doivent être actifs après le démarrage (consultez systemd.special(7) pour plus de détails). Pour l'utiliser, ajoutez WantedBy=timers.target à la section [Install] de votre timer et activez l'unité timer.

Unités service

Pour chaque fichier ".timer", il existe un fichier ".service" correspondant (par exemple, truc.timer et truc.service). Le fichier timer active et contrôle le fichier service. Le service ne nécessite pas de section [Install] car ce sont les unités timer qui sont activées. Si nécessaire, il est possible de contrôler une unité portant un nom différent en utilisant l'option Unit= dans la section [Timer] du timer.

Gestion

Pour utiliser une unité timer activez et démarrez-la comme toute autre unité (n'oubliez pas d'ajouter le suffixe .timer). Pour voir tous les timers démarrés, exécutez :

$ 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

Note:

• Pour lister tous les timers (y compris les inactifs), utilisez systemctl list-timers --all.
• L'état d'un service démarré par un timer sera probablement inactif, sauf s'il est en cours de déclenchement.
• Si un timer s'est désynchronisé, il peut être utile de supprimer son fichier stamp-* dans /var/lib/systemd/timers. (ou ~/.local/share/systemd/ dans le cas de timers utilisateur). Ce sont des fichiers de longueur nulle qui marquent la dernière fois que chaque minuterie a été exécutée. S'ils sont supprimés, ils seront reconstruits au prochain démarrage de leur timer.

Exemples

Un fichier d'unité de service peut être planifié avec un timer par défaut. Les exemples suivants planifient l'exécution de truc.service avec un temporisateur correspondant appelé truc.timer.

Minuterie monotone

Une minuterie qui démarre 15 minutes après le démarrage et qui recommence toutes les semaines pendant que le système fonctionne.

/etc/systemd/system/truc.timer

[Unit]
Description=Exécuter truc chaque semaine et au démarrage

[Timer]
OnBootSec=15min
OnUnitActiveSec=1w

[Install]
WantedBy=timers.target

Minuterie en temps réel

Une minuterie qui se déclenche une fois par semaine (à 12h00 le lundi). Lorsqu'il est activé, il déclenche le service immédiatement s'il a manqué la dernière heure de démarrage (option Persistent=true), par exemple en raison de la mise hors tension du système :

/etc/systemd/system/truc.timer

[Unit]
Description=Exécuter truc chaque semaine

[Timer]
OnCalendar=weekly
Persistent=true

[Install]
WantedBy=timers.target

Lorsque des dates et des heures plus spécifiques sont requises, les événements OnCalendar utilisent le format suivant :

DayOfWeek Year-Month-Day Hour:Minute:Second

Un astérisque peut être utilisé pour spécifier n'importe quelle valeur et des virgules peuvent être utilisées pour énumérer les valeurs possibles. Deux valeurs séparées par .. indiquent une plage contiguë.

Dans l'exemple ci-dessous, le service est lancé les quatre premiers jours de chaque mois à 12h00, mais seulement si ce jour est un lundi ou un mardi.

OnCalendar=Mon,Tue *-*-01..04 12:00:00

Pour lancer un service le premier samedi de chaque mois, utilisez :

OnCalendar=Sat *-*-1..7 18:00:00

Lorsque vous utilisez la partie DayOfWeek, vous devez spécifier au moins un jour de la semaine. Si vous voulez que quelque chose s'exécute tous les jours à 4 heures du matin, utilisez :

OnCalendar=*-*-* 4:00:00

Pour exécuter un service à différents moments, OnCalendar peut être spécifié plusieurs fois. Dans l'exemple ci-dessous, le service fonctionne à 22h30 les jours de semaine et à 20h00 le week-end.

OnCalendar=Mon..Fri 22:30
OnCalendar=Sat,Sun 20:00

De plus amples informations sont disponibles dans systemd.time(7).

Astuce:

• Les spécifications temporelles de OnCalendar peuvent être testées afin de vérifier leur validité et de calculer le temps suivant où la condition s'écoulera lorsqu'elles sont utilisées sur un fichier d'unité de temporisation avec l'option calendar de l'utilitaire systemd-analyze. Par exemple, on peut utiliser systemd-analyze calendar weekly ou systemd-analyze calendar "Mon,Tue *-*-01..04 12:00:00".
• La commande faketime est particulièrement utile pour tester divers scénarios avec la commande ci-dessus ; elle est fournie avec le paquetlibfaketime.
• Les expressions d'événements spéciaux comme daily et weekly font référence à des heures de début spécifiques et, par conséquent, toutes les minuteries partageant ces événements de calendrier démarreront simultanément. Les minuteries partageant des événements de démarrage peuvent entraîner une baisse des performances du système si les services des minuteries sont en concurrence pour les ressources du système. L'option RandomizedDelaySec de la section [Timer] évite ce problème en décalant de manière aléatoire l'heure de démarrage de chaque minuterie. Consultez systemd.timer(5).
• Ajouter l'option AccuracySec=1us à la section [Timer], pour éviter l'imprécision de la valeur par défaut de AccuracySec de 1m. Consultez également systemd.timer(5).

Unités transitoires timer

On peut utiliser systemd-run pour créer des unités transitoires .timer. C'est-à-dire que l'on peut configurer une commande pour qu'elle s'exécute à un moment précis sans avoir de fichier de service. Par exemple, la commande suivante touche un fichier après 30 secondes :

# systemd-run --on-active=30 /bin/touch /tmp/truc

On peut également spécifier un fichier de service préexistant qui n'a pas de fichier de temporisation. Par exemple, la commande suivante démarre l'unité systemd nommée unitequelconque.service après que 12,5 heures se soient écoulées :

# systemd-run --on-active="12h 30m" --unit unitequelconque.service

Consultez systemd-run(1) pour plus d'informations et d'exemples.

En tant que remplacement de cron

Bien que cron soit sans doute le planificateur de tâches le plus connu, les minuteries systemd peuvent être une alternative.

Avantages

Les principaux avantages de l'utilisation des timers proviennent du fait que chaque tâche a son propre service systemd. Certains de ces avantages sont :

• Les tâches peuvent être facilement lancées indépendamment de leurs timers. Cela simplifie le débogage.
• Chaque tâche peut être configurée pour s'exécuter dans un environnement spécifique (consultez systemd.exec(5)).
• Les tâches peuvent être attachées à des cgroups.
• Les tâches peuvent être configurées pour dépendre d'autres unités systemd.
• Les tâches sont enregistrées dans le journal systemd pour faciliter le débogage.

Avertissements

Certaines choses qui sont faciles à faire avec cron sont difficiles à faire avec les unités de temporisation seules :

• Création : pour configurer une tâche minutée avec systemd, vous devez créer deux fichiers et exécuter des commandes systemctl, alors qu'il suffit d'ajouter une simple ligne à une crontab.
• Courriers électroniques : il n'y a pas d'équivalent intégré à MAILTO de cron pour l'envoi de courriers électroniques en cas d'échec de la tâche. Consultez la section suivante pour un exemple de mise en place d'une fonctionnalité similaire en utilisant OnFailure=.

Notez également que les minuteries de l'utilisateur ne s'exécutent par défaut que lorsqu'une session de connexion de l'utilisateur est active. Cependant, la persistance peut permettre aux services de s'exécuter au démarrage même lorsque l'utilisateur n'a pas de session de connexion active.

MAILTO

Vous pouvez configurer systemd pour qu'il envoie un courrier électronique lorsqu'une unité échoue. Cron envoie un courrier à MAILTO si la tâche affiche du contenu sur stdout ou stderr, mais de nombreuses tâches sont configurés pour n'afficher qu'en cas d'erreur. Vous avez d'abord besoin de deux fichiers : un exécutable pour envoyer le courrier et un .service pour démarrer l'exécutable. Pour cet exemple, l'exécutable est juste un script shell utilisant sendmail, qui se trouve dans les paquets qui fournissent smtp-forwarder.

/usr/local/bin/systemd-email

#!/bin/sh

/usr/bin/sendmail -t <<ERRMAIL
To: $1
From: systemd <root@$HOSTNAME>
Subject: $2
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8

$(systemctl status --full "$2")
ERRMAIL

Quel que soit l'exécutable que vous utilisez, il devrait probablement accepter au moins deux arguments comme le fait ce script shell : l'adresse à laquelle envoyer et le fichier de l'unité dont il faut obtenir l'état. Le .service que nous créons passera ces arguments :

/etc/systemd/system/status_email_user@.service

[Unit]
Description=Courriel d'état pour %i à utilisateur.

[Service]
Type=oneshot
ExecStart=/usr/local/bin/systemd-email adresse %i
User=nobody
Group=systemd-journal

Où user est l'utilisateur qui reçoit le courriel et address est l'adresse courriel de cet utilisateur. Bien que le destinataire soit codé en dur, le fichier de l'unité à rapporter est transmis comme paramètre d'instance, de sorte que ce service unique peut envoyer des courriels pour de nombreuses autres unités. À ce stade, démarrez status_email_user@dbus.service pour vérifier que vous pouvez recevoir les courriels.

Ensuite, éditez simplement le service pour lequel vous voulez recevoir des courriels et ajoutez OnFailure=status_email_user@%n.service à la section [Unit]. %n transmet le nom de l'unité au modèle.

Note:

• Si vous configurez la sécurité sSMTP conformément à sSMTP#Security, l'utilisateur nobody n'aura pas accès à /etc/ssmtp/ssmtp.conf, et la commande systemctl start status_email_user@dbus.service échouera. Une solution consiste à utiliser root comme utilisateur dans l'unité status_email_user@.service.
• Si vous essayez d'utiliser mail -s somelogs address dans votre script de courriel, mail va forker et systemd va tuer le processus de courriel lorsqu'il consultera votre script. Évitez ce comportement en faisant mail -Ssendwait -s somelogs address.

Utilisation d'une crontab

Plusieurs de ces problèmes peuvent être contournés en installant un paquet qui analyse une crontab traditionnelle pour configurer les timers. systemd-cron-next-git^AUR et systemd-cron^AUR sont deux de ces paquets. Ils peuvent fournir la fonctionnalité MAILTO manquante.

De plus, comme avec les crontabs, une vue unifiée de tous les travaux planifiés peut être obtenue avec systemctl. Consultez #Gestion.

Voir aussi

• systemd.timer(5)
• Fedora:Features/SystemdCalendarTimers
• Gentoo:Systemd#Timer services
• systemd-cron-next — outil pour générer des minuteries/services à partir des fichiers crontab et anacrontab

https://github.com/systemd-cron/systemd-cron-next || systemd-cron-next-git^AUR

• systemd-cron — provides systemd units to run cron scripts ; using systemd-crontab-generator to convert crontabs

https://github.com/systemd-cron/systemd-cron || systemd-cron^AUR

• Timers Systemd pour la planification des tâches