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.

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 :

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

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

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

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^AUR 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 . Consultez #Gestion.

Voir aussi

gollark: Ah. PHP.

gollark: I recommend using x86 assembly, ARM stuff isn't really as widely used.

gollark: Some weird people have written webapps in assembly, even.

gollark: Why shouldn't they?

gollark: Not everyone is sensible.

This article is issued from Archlinux. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.