En quoi consiste exactement «un arrêt de travail», comme dans «Un arrêt de travail est en cours…»?

Après l'émission d'une commande d'arrêt, on obtient parfois un message d'état comme celui-ci:

A stop job is running for Session 1 of user xy

et puis le système se bloque pendant un certain temps, ou pour toujours selon ???

Alors, qu'est-ce qu'un "arrêt de travail"?

Aussi, pourquoi estime-t-il parfois le temps qu'il faudra, assez précisément, et d'autres fois, il peut fonctionner indéfiniment?

systemd fonctionne en interne en termes de file d'attente de "jobs". Chaque tâche (en simplifiant un peu) est une action à entreprendre: arrêter, vérifier, démarrer ou redémarrer une unité particulière .

Lorsque (par exemple) vous demandez à systemd de démarrer une unité de service , il établit une liste de travaux d'arrêt et de démarrage pour toutes les unités (unités de service, unités de montage, unités de périphérique, etc.) nécessaires pour atteindre cet objectif, selon les exigences et les dépendances de l'unité, les ordonne, selon les relations de commande d'unité, élabore et (si possible) corrige les auto-contradictions et (si cette dernière étape réussit) les place dans la file d'attente.

Il essaie ensuite d'exécuter les "travaux" mis en file d'attente.

Un travail d'arrêt est en cours d'exécution pour la session 1 de l'utilisateur xy

Le nom d'affichage de l' unité est ici Session 1 of user xy. Ce sera (à partir du nom d'affichage) une unité de session , pas une unité de service . Il s'agit de l'abstraction de session de connexion à l'espace utilisateur qui est maintenue par le logindprogramme de systemd et ses plugins PAM. Il s'agit (en substance et en théorie) d'un regroupement de tous les processus que cet utilisateur exécute en tant que «session de connexion» quelque part.

Le travail qui a été mis en file d'attente est stop. Et cela prend probablement beaucoup de temps car les gens de systemd ont confondu par erreur le blocage de la session avec l' arrêt de la session . Ils cassent les premiers pour faire travailler les seconds, et en réponse, certaines personnes modifient le système pour casser les seconds afin de faire travailler les premiers. Les gens du système devraient vraiment reconnaître que ce sont deux choses différentes.

Dans votre session de connexion, vous avez quelque chose qui ignore SIGTERMou qui met beaucoup de temps à se terminer une fois qu'il a vu SIGTERM. Ironiquement, le premier est le comportement de longue date de certains obus de contrôle du travail. La bonne façon de terminer les chefs de session de connexion lorsqu'ils sont ces shells de contrôle de travail particuliers est de leur dire que la session a été suspendue , après quoi ils terminent tous leurs travaux (un type de travail différent du travail systemd interne), puis se résilier.

Ce qui se passe réellement, c'est que systemd attend le délai d'arrêt de l'unité jusqu'à ce qu'il y ait recours SIGKILL. Cette temporisation est configurable par unité, bien sûr, et peut être définie pour ne jamais expirer. D'où la raison pour laquelle on peut potentiellement voir différents comportements.

Lectures complémentaires

• Lennart Poettering (2015). systemd . pages de manuel de systemd. Freedesktop.org.
• Jonathan de Boyne Pollard (2016-06-01). systemd tue les processus d'arrière-plan après la déconnexion de l'utilisateur . 825394. Suivi des bogues Debian.
• Lennart Poettering (2015). systemd.kill . pages de manuel de systemd. Freedesktop.org.
• Lennart Poettering (2015). systemd.service . pages de manuel de systemd. Freedesktop.org.
• Pourquoi bash ignore-t-il SIGTERM?
• /superuser/1102242/

Ces messages proviennent de systemd, qui est un système init qui démarre et arrête les travaux. Les tâches peuvent être des démons, mais peuvent également effectuer de petites tâches telles que le montage et le démontage de disques, la suppression de / tmp ou l'enregistrement et la restauration de la luminosité de l'écran pendant le démarrage. systemctl list-unitsvous donne l'idée. Systemd utilise "unité" et "travail" pour signifier à peu près la même chose.

Lorsqu'un travail est arrêté, comme c'est le cas systemctl stop ..., la question est de savoir combien de temps attendre la fin du travail avant de déclarer l'échec et de tuer les processus du travail avec le SIGKILLsignal. Nous ne voulons vraiment pas l'utiliser à SIGKILLmoins que nous ne le soyons, car cela ne donne pas la possibilité au processus de se terminer proprement. Pour certains processus, quelques secondes peuvent être suffisantes pour déclarer un échec, pour d'autres processus comme une base de données, il peut y avoir des E / S réseau et disque substantielles pour que le travail s'arrête proprement, et nous pouvons donc donner à ces unités plusieurs minutes pour s'arrêter proprement. .

Ce que vous voyez à l'arrêt est l'équivalent systemctl stop $UNIT_NAMEdont l'exécution prend un certain temps. Il y a un compteur qui indique les secondes écoulées et le temps d'attente maximum avant que SIGKILL soit émis et que l'arrêt se poursuive malgré tout.

Sauf s'il existe de bonnes raisons de s'attendre à un long délai, cela indique généralement une sorte de dysfonctionnement. Cela peut aller d'un serveur DHCP ne répondant pas à une version et donc l'action de libération devant expirer, ou d'une erreur provoquant la fermeture d'un démon.

Certains services sont bloqués et systemd attend qu'il se termine. Systemd n'est probablement pas en train d'estimer avec précision le temps qu'il faudra, le temps (généralement 90 secondes) est le temps que systemd attendra avant de manquer de patience. Voir cet article:

Un travail d'arrêt est en cours d'exécution pour la session c2 de l'utilisateur

Les «arrêts de travail» sont quand systemdattend un arrêt de «travail» spécifique, par exemple un processus qu'il attend de terminer avant de continuer. Si vous voyez un message d'avertissement indiquant "qu'un travail d'arrêt est en cours d'exécution ..." (etc.), cela signifie techniquement que quelque chose est en attente dans la file d'attente des travaux.

Cependant, avant de parcourir toute la file d'attente des tâches système, gardez à l'esprit que parfois ces messages d'avertissement sont un résultat indirect de facteurs environnementaux (en fait, le message est même référencé sur leur dépôt GitHub comme un bogue possible).

Par exemple: nous recevions des messages liés à "stop job" et nous ne pouvions pas comprendre pourquoi .... se révèle, le disque était presque à court d'espace, et il a commencé à faire en sorte que le système d'exploitation se comporte étrangement.

La mise à niveau du serveur vers un disque plus gros et le redémarrage l'ont corrigé;)