L'unité de temporisation systemd ignore-t-elle la prochaine exécution si le processus n'est pas encore terminé?

Je veux utiliser systemd pour exécuter une commande toutes les 5 minutes. Cependant, il existe un risque que la tâche prenne parfois plus de 5 minutes. À ce stade, systemd démarrera-t-il une deuxième instance de la commande, c'est-à-dire que je finirai avec 2 processus en cours?

Est-il possible de dire à systemd de ne pas démarrer un deuxième processus si le premier n'est pas terminé? Sinon, quelles sont les bonnes solutions de contournement?

Remarque: j'espère que la réponse est "C'est le comportement par défaut. Il n'est tout simplement pas documenté." Si tel est le cas, quelqu'un peut-il me dire comment déposer un bogue contre ses documents?

Remarque: Cron a un problème similaire qui est abordé dans /unix//a/173928/11244 . Je cherche l'équivalent systemd.

cron systemd

— TomOnTime
source

Il s'agit du comportement par défaut (et le seul). Il n'est pas explicitement documenté, mais est impliqué par la logique de fonctionnement de systemd.

systemd.timer (5) se lit comme suit:

Pour chaque fichier de temporisation, un fichier d'unité correspondant doit exister, décrivant l'unité à activer lorsque le temporisateur s'est écoulé .

systemd (1) , à son tour, décrit le concept des états unitaires et des transitions entre eux:

Les unités peuvent être "actives" (signifiant démarrées, liées, branchées, ..., selon le type d'unité, voir ci-dessous), ou "inactives" (signifiant arrêtées, non liées, débranchées, ...), ainsi que dans le processus d'activation ou de désactivation , c'est-à-dire entre les deux états (ces états sont appelés "activation", "désactivation").

Cela signifie que le déclenchement d'un temporisateur conduit à "l'activation" de l'unité d'adaptation, c'est-à-dire sa transition vers l'état "actif".

Si l'unité correspondante est déjà "active" au moment de "l'activation" (pour une unité de service, cela signifie "le processus principal est toujours en cours", sauf si l'unité de service a Type=oneshotet RemainAfterExit=true), il devrait être évident qu'aucune action ne sera pris.

— intelfx
source

Pourriez-vous clarifier les services "oneshot"? À mon avis, un service "oneshot" ne devrait en aucun cas exécuter une autre copie (page de manuel: le processus doit se terminer avant que systemd ne démarre les unités de suivi)

— Gima

@Gima une unité one-shot sans aucun paramètre supplémentaire est considérée comme "en cours d'activation" pendant que son processus initial est en cours d'exécution et devient "inactive" à sa sortie. À ce moment, un autre déclencheur peut réactiver cette unité.

— intelfx

@Gima ... cependant, une unité one-shot qui reste RemainAfterExit=truerestera "active" lorsque son processus initial se termine, donc les déclencheurs suivants d'une minuterie seront ignorés à moins qu'un administrateur ne désactive (arrête) explicitement cette unité, ou qu'elle soit arrêtée par négatif dépendances.

— intelfx

Je continue de recevoir des représentants lorsque les gens l'invitent. J'espère que systemd ne clarifie pas leurs documents.

— TomOnTime

Cela fait maintenant partie de la documentation de systemd -

Note that in case the unit to activate is already active at the time the timer elapses it is not restarted, but simply left running. There is no concept of spawning new service instances in this case.

freedesktop.org/software/systemd/man/systemd.timer.html

— Sam