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
puis le système se bloque pendant un certain temps, ou pour toujours selon ???
Alors, qu'est-ce qu'un "arrêt de travail" exactement ?
De plus, pourquoi estime-t-il parfois le temps que cela prendra, assez précisément, et d'autres fois, il peut durer indéfiniment ?
Réponse acceptée :
systemd fonctionne en interne en termes de file d'attente de "tâches". Chaque emploi (en simplifiant un peu) est une action à effectuer :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 tâches 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, en fonction des exigences et des dépendances de l'unité, les ordonne, en fonction des relations d'ordre des unités , résout et (si possible) corrige toutes les contradictions, et (si cette dernière étape réussit) les place dans la file d'attente.
Ensuite, il essaie d'exécuter les "travaux" en file d'attente.
Une tâche d'arrêt est en cours d'exécution pour la session 1 de l'utilisateur xy
L'unité nom d'affichage voici la Session 1 of user xy . Ce sera (à partir du nom d'affichage) une session unité, pas un service unité. Il s'agit de l'abstraction de la session de connexion de l'espace utilisateur qui est maintenue par le logind de systemd programme 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 parce que les personnes systemd ont confondu par erreur la session raccrocher avec fermeture de la session . Ils cassent le premier pour faire fonctionner le second, et en réponse, certaines personnes modifient le système pour casser le second pour faire fonctionner le premier. Les gens de systemd devraient vraiment reconnaître qu'il s'agit de deux choses différentes.
Dans votre session de connexion, vous avez quelque chose qui ignore SIGTERM ou qui prend beaucoup de temps à se terminer une fois qu'il a vu SIGTERM . Ironiquement, le premier est le comportement de longue date de certains shells de contrôle des tâches. La bonne façon de mettre fin aux leaders de session de connexion lorsqu'ils sont ces shells de contrôle de travail particuliers est de leur dire que la session a été raccrochée , après quoi ils mettent fin à tous leurs travaux (un type de travail différent du travail systemd interne) puis se terminent eux-mêmes.
Ce qui se passe réellement, c'est que systemd attend le délai d'arrêt de l'unité jusqu'à ce qu'il recoure à SIGKILL . Ce délai d'expiration est configurable par unité, bien sûr, et peut être défini pour ne jamais expirer. D'où la possibilité de voir des comportements différents.
Autres lectures
- Lennart Poettering (2015). systemd. pages de manuel 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. Outil de suivi des bogues Debian.
- Lennart Poettering (2015). systemd.kill. pages de manuel systemd. Freedesktop.org.
- Lennart Poettering (2015). systemd.service. pages de manuel systemd. Freedesktop.org.
- Pourquoi bash ignore-t-il SIGTERM ?
- https://superuser.com/questions/1102242/