< Systemd (Français)

systemd (Français)/Timers (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.

É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

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 et .

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

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 ). Le fichier timer active et contrôle le fichier service. Le service ne nécessite pas de section 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 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 :

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 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.

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 ), par exemple en raison de la mise hors tension du système :

Lorsque des dates et des heures plus spécifiques sont requises, les événements 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 , 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, 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 .

Unités transitoires timer

On peut utiliser 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 après que 12,5 heures se soient écoulées :

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

Consultez 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 ).
  • 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é à 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 .

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 à 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 , qui se trouve dans les paquets qui fournissent smtp-forwarder.

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 :

Où est l'utilisateur qui reçoit le courriel et 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 pour vérifier que vous pouvez recevoir les courriels.

Ensuite, éditez simplement le service pour lequel vous voulez recevoir des courriels et ajoutez à la section . 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. et sont deux de ces paquets. Ils peuvent fournir la fonctionnalité 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
https://github.com/systemd-cron/systemd-cron || systemd-cronAUR
This article is issued from Archlinux. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.