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

56

Le message suivant apparaît presque chaque fois que j'éteins mon ordinateur:

A stop job is running for Session c2 of user ... (1min 30s)

Il attend 1min30s puis continue le processus d'arrêt. Je suis ce guide de diagnostic d'arrêt systemd et récupère le fichier shutdown-log.txt (je ne peux pas coller directement le journal ici car il est très long). Malheureusement, je ne comprends pas le journal par moi-même. Quelqu'un pourrait-il m'aider à découvrir ce qui empêche mon système de s'arrêter correctement?

Je lance Arch Linux avec le noyau 4.4.5-1-ARCH, ma systemdversion est 229-3.

Ajout 1: Je remarque que chaque fois que je me déconnecte puis que j'éteins mon ordinateur à partir de l'écran de connexion, il ne reçoit pas le message A stop job is running.... J'ai essayé de me déconnecter plusieurs fois avant l'arrêt, alors je pense que cela n'arrive pas par hasard. J'espère que cette information pourrait aider.

Addition 2: C'est toujours la session c2 qui cause l'arrêt de l'arrêt. Donc, comme @ n.st le suggère, j’ai regardé à nouveau dans Diagnostic des problèmes d’arrêt et enregistré à la loginctl session-status c2place dmesg, mais il n’y a alors rien sur shutdown-log.txt. J'ai remplacé loginctl session-status c2par systemd-cglset obtenu le journal suivant:

Control group /:
-.slice
└─init.scope
  ├─   1 /usr/lib/systemd/systemd-shutdown reboot --log-level 6 --log-target ...
  ├─1069 /usr/lib/systemd/systemd-shutdown reboot --log-level 6 --log-target ...
  ├─1071 /bin/sh /usr/lib/systemd/system-shutdown/debug.sh reboot
  └─1074 systemd-cgls

Des idées?

Remarque: après la mise à jour du noyau 4.6.4-1-ARCHet systemd 230-7l'erreur, l'erreur ne s'est plus produite.

Macnguyen
la source
Malheureusement, le dmesgrésultat que vous avez collé n’est pas très informatif. Il indique la déconnexion Wi-Fi lorsque vous appuyez sur le bouton d’arrêt (3048 secondes après le démarrage du système), puis rien jusqu’à expiration du délai de 1m30 et la fermeture du système (à 3139 secondes).
n.
1
Pour vérifier ce qui est en cours d'exécution dans cette sinistre session c2 qui ne se termine pas seul, utilisez loginctl session-status c2. Je ne sais pas si vous pouvez toujours passer à un getty pendant l'arrêt, mais essayez d'appuyer sur Ctrl + Alt + F2 lorsque "Un travail d'arrêt en cours d'exécution ..." s'affiche. Si cela fonctionne, vous recevrez une invite de connexion et pourrez utiliser la loginctlcommande. Si vous ne recevez pas d'invite de connexion, suivez les mêmes étapes que celles que vous avez suivies dmesg, mais enregistrez le résultat loginctl session-status c2. (Tout cela en supposant que c'est toujours "c2" qui est suspendu, pas une session à chaque fois.)
n.st
1
Vous pouvez obtenir un correctif (temporaire) par ce hack: Créer /etc/sysctl.d/50-coredump.confavec le contenu :,kernel.core_pattern=core réf: github.com/systemd/systemd/issues/1615#issuecomment-203507283
Runium
1
github.com/systemd/systemd/issues/2691 Cela peut être pertinent
Natecat le
2
@aurelien Est-ce toujours c2 qui cause la minuterie à l'arrêt? Si tel est le cas, vous pouvez suivre à nouveau le diagnostic des problèmes d'arrêt et le stocker loginctl session-status c2au lieu de dmesg.
n.st

Réponses:

45

Une solution de contournement à ce problème consiste à réduire ce délai /etc/systemd/system.confde 90 à 10 jours, par exemple:

DefaultTimeoutStopSec=10s

et lancez la commande suivante dans le terminal après avoir effectué les modifications

$ systemctl daemon-reload
MightyPork
la source
9
cela n'explique ni ne résout le problème, attendre aussi 10 secondes et même ne pas avoir d'arrêt propre n'est pas génial du tout
jcora
Y at-il un travail qui prend plus de 10 pour arrêter?
Jared Chu
10

Ce problème peut avoir plusieurs causes, aussi des réponses spécifiques ne fonctionnent-elles pas très bien. Essayez ceci pour le dépannage:

  1. attendez que le message "Un travail d'arrêt est en cours d'exécution pour la Session c2 ..." s'affiche à l'arrêt et redémarre une fois l'arrêt terminé
  2. lancez journalctl -p5dans un terminal et appuyez sur ENDpour atteindre la fin du journal systemd ( -p5filtre beaucoup de déchets)
  3. lancez une recherche en appuyant sur /et entrez le terme recherchétimed out. Killing.
  4. rechercher en arrière en appuyant SHIFT+Nplusieurs fois sur
  5. la ligne en dessous de chaque match vous indique quelle application s'est mal comportée:Killing process 1234 (jack_thru) with signal SIGKILL.

Si c'est toujours la même application, vous voulez savoir ce qu'elle fait et pourquoi elle n'est pas arrêtée à l'arrêt. Sinon, le problème pourrait être plus compliqué à résoudre, mais vous pourriez tout de même avoir un indice ou deux.

Bonne chance! :)

mzuther
la source
1
Merci pour cette réponse correcte. Je l'ai utilisé pour constater que, dans mon cas, les notifications Fedora 30 "lpf" en étaient la cause, et dans lpf-gui Désélectionnées Notifications | Activer les notifications.
mardi
5

J'ai eu le même problème, en cherchant j'ai trouvé un post dans un forum reddit d'Arch Linux.

Voici la solution qui fonctionne pour moi https://www.reddit.com/r/archlinux/comments/4bawf7/a_stop_job_is_running_for_session_c2_of_user/d17th3u

Installer un chien de garde

# pacman -S watchdog

Et puis démarrez le service au démarrage:

# systemctl enable watchdog.service

Démarrer le service pour ne plus voir le message

# systemctl start watchdog.service

Je crée un contenu essentiel pour cette https://gist.github.com/dianjuar/98d02af4050dc2df8ae6f18695d44ca3

Diego Juliao
la source
J'ai suivi votre guide, mais cela ne résout pas le problème. Merci quand même.
macnguyen
2
Y at-il d'autres implications à ce correctif? Apparemment, watchdog le matériel réinitialisera le système s'il tarde ou échoue à d'autres tests. Ainsi, lorsque la temporisation de la question survient, le chien de garde réinitialise l'ordinateur. Je me demande si le système s’arrêterait plus proprement si nous réduisions simplement le délai d’attente comme indiqué dans l’ autre réponse. Je me demande également si watchdogcela forcerait une réinitialisation dans d'autres situations indésirables.
Sparhawk
Je lis votre homme page. Je pense que ce chien de garde empêche la réinitialisation de dire au noyau Linux que tout va bien,
Diego Juliao
> Il ouvre / dev / watchdog et continue à écrire dessus assez souvent pour empêcher le noyau de se réinitialiser, au moins une fois par minute.
Diego Juliao
Aucun paquet nommé watchdog sur OpenSuSE, cela ne m'aide donc pas vraiment :(
David Faure
4

J'ai trouvé une solution ici qui a fonctionné pour moi avec Debian 9 sur vbox. J'obtenais le délai typique de 120 secondes à l'arrêt ou au redémarrage.

https://forums.kali.org/showthread.php?32498-Delay-90-seconds-on-shutdown

Faites comme Ironman dit:

La solution consiste à ouvrir le shell et à «arrêter maintenant», puis lorsque la machine se rallume, effectuez un «redémarrage». Le message disparaît et les redémarrages ultérieurs ne sont plus bloqués.

J'ai utilisé "sudo shutdown now" et le délai de redémarrage a maintenant disparu. Cela semble trop simple, mais cela a fonctionné pour moi (et les autres).

HTH

Dennis Cote
la source
8
Pourquoi cette réponse a-t-elle tant de votes positifs? Cela n'a pas fonctionné pour moi, et cela ne donne aucune idée de la raison pour laquelle cela devrait fonctionner.
Rodrigo
Travaillé pour moi, mais on ne sait toujours pas pourquoi.
pstryk
3

Avoir eu un problème similaire sur Kali [2017.01], avec un délai de déconnexion alterné affiché par:

"Un travail d'arrêt est en cours d'exécution pour la session c1 de l'utilisateur Debian-gdm"

"Un travail d'arrêt est en cours d'exécution pour le gestionnaire d'utilisateurs pour l'UID 132"

J'ai réussi à éliminer une erreur en m'arrêtant NetworkManageravant l'arrêt ou en la désactivant, avec:

# To get rid of: "A stop job is running for User manager for UID 132"
systemctl disable NetworkManager 
systemctl stop NetworkManager 

Cela devrait probablement être corrigé ou mis d'une autre manière lors du redémarrage.

En ce qui concerne l'autre délai, je n'ai pas réussi. Il semble que cela puisse être lié à GDM ( Gnome Display Manager ), pulseaudioou dbus. Donc, comme je ne pouvais pas isoler le problème, le seul moyen était de définir les DefaultTimeout*Sec=5sentrées system.confcomme déjà mentionné dans d'autres publications.

D'autres problèmes pouvant faire l'objet d'une enquête sont présentés dans:

# systemctl --state=masked --state=not-found --state=failed

  UNIT                           LOAD      ACTIVE   SUB  DESCRIPTION                   
 tmp.mount                      not-found inactive dead tmp.mount                     
 auditd.service                 not-found inactive dead auditd.service                
 console-screen.service         not-found inactive dead console-screen.service        
 festival.service               not-found inactive dead festival.service              
 kbd.service                    not-found inactive dead kbd.service                   
 live-tools.service             masked    inactive dead live-tools.service            
 plymouth-quit-wait.service     not-found inactive dead plymouth-quit-wait.service    
 plymouth-quit.service          not-found inactive dead plymouth-quit.service         
 plymouth-start.service         not-found inactive dead plymouth-start.service        
 systemd-sysusers.service       not-found inactive dead systemd-sysusers.service      
 systemd-update-done.service    not-found inactive dead systemd-update-done.service   
 systemd-vconsole-setup.service not-found inactive dead systemd-vconsole-setup.service
 syslog.target                  not-found inactive dead syslog.target                 

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

et:

# systemd-cgls -u user-132.slice

Unit user-132.slice (/user.slice/user-132.slice):
├─user@132.service
 ├─pulseaudio.service
  └─739 /usr/bin/pulseaudio --daemonize=no
 ├─at-spi-dbus-bus.service
  ├─704 /usr/lib/at-spi2-core/at-spi-bus-launcher
  ├─709 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3
  └─712 /usr/lib/at-spi2-core/at-spi2-registryd --use-gnome-session
 ├─dbus.service
  └─694 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
 └─init.scope
   ├─597 /lib/systemd/systemd --user
   └─600 (sd-pam)
└─session-c1.scope
  ├─577 gdm-session-worker [pam/gdm-launch-environment]
  ├─613 /usr/lib/gdm3/gdm-x-session gnome-session --autostart /usr/share/gdm/greeter/autostart
  ├─618 /usr/lib/xorg/Xorg vt1 -displayfd 3 -auth /run/user/132/gdm/Xauthority -background none -noreset -keeptty -verbose 3
  ├─697 /usr/lib/gnome-session/gnome-session-binary --autostart /usr/share/gdm/greeter/autostart
  ├─721 /usr/bin/gnome-shell
  └─752 /usr/lib/gnome-settings-daemon/gnome-settings-daemon
not2qubit
la source
2
Cette réponse nous donne au moins quelques informations sur la façon de trouver ce qui (parmi les nombreuses possibilités) pourrait causer le problème sur nos machines individuelles. Encore un autre problème est qu’après un poweroffou shutdownnous ne pouvons pas nous connecter pour voir le coupable. systemd doit enregistrer la sortie de cgls lorsque ce problème se produit. Le mieux que nous puissions faire pour le moment est d’enregistrer la sortie systemd-cglset de la consulter plus tard si / quand le blocage se reproduit.
Duanev
2

Comme il s’agit de l’un des premiers résultats du moteur de recherche le plus convivial jamais créé, j’ajouterai ma solution ici: j’utilise Arch Linux avec le bureau Gnome; noyau actuel à ce jour: 4.16.

J'ai reçu le message A stop job is running for Session c2 of user ... (1min 30s)chaque fois qu'il a Remote Loginété activé Settings > Sharinget a Sharingété activé.

Chaque fois que je désactivais cela, mon ordinateur s’arrêtait joliment en utilisant le bouton d’arrêt Gnome.

Puisque "Connexion à distance" n’est rien d’autre que SSH, je suppose que la réponse de not2qubit fonctionnera également, car la désactivation de NetworkManager désactivera probablement également SSH.

Stueja
la source
1

Parfois, cela peut être causé par une application. Se souvenir des modifications apportées juste avant que cela ne se produise peut être utile pour en déterminer la cause. J'ai eu le même problème après l'installation skypeforlinux-stable-binsur Arch Linux. La fermeture de cette application avant de fermer le système a résolu le problème (j'ai écrit un script pour le faire automatiquement avant de fermer).

prosoitos
la source
0

J'ai eu ce problème pendant longtemps, alors j'ai pensé partager ma solution.

Le problème était que Google Chrome fonctionnait en arrière-plan et ne se fermait pas lors de la mise hors tension de l'ordinateur. La meilleure solution consiste donc à désactiver cette fonctionnalité.

  1. Accédez aux paramètres de Google Chrome.
  2. Cliquez sur "Avancé".
  3. Allez dans "Système".
  4. Désactivez "Continuer à exécuter les applications en arrière-plan lorsque Google Chrome est fermé".

entrez la description de l'image ici

Cela a résolu le problème pour moi. J'espère que ça aide.

ArianJM
la source