web-dev-qa-db-fra.com

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

Le message suivant apparaît presque chaque fois que j'arrête mon ordinateur:

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

Il attend 1min30s puis poursuit le processus d'arrêt. Je suis ce guide de diagnostic de l'arrêt systemd et j'obtiens 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 à savoir pourquoi mon système ne s'arrête pas correctement?

J'exécute Arch Linux avec le noyau 4.4.5-1-Arch, ma version systemd est 229-3.

Addition 1: J'observe que chaque fois que je me déconnecte, puis é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 avant l'arrêt plusieurs fois, donc je pense que cela ne se produit pas par hasard. J'espère que ces informations pourraient vous aider.

Addition 2: C'est toujours la session c2 qui provoque l'arrêt de l'arrêt. Donc, comme @ n.st le suggère, j'ai regardé Diagnostic des problèmes d'arrêt à nouveau et stocké loginctl session-status c2 au lieu de dmesg, mais il n'y a rien sur le shutdown-log.txt. J'ai remplacé loginctl session-status c2 par systemd-cgls et a 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 avoir mis à jour le noyau 4.6.4-1-Arch et systemd 230-7, l'erreur ne s'est plus produite.

systemdshutdown
67
macnguyen

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

DefaultTimeoutStopSec=10s

et exécutez la commande suivante dans le terminal après avoir apporté des modifications

$ systemctl daemon-reload
46
MightyPork

Ce problème peut avoir de nombreuses causes, donc les réponses spécifiques ne fonctionnent pas trop 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 ..." apparaisse à l'arrêt et redémarrez une fois l'arrêt terminé
  2. exécutez journalctl -p5 dans un terminal et appuyez sur END pour arriver à la fin du journal systemd (-p5 filtre beaucoup de déchets)
  3. lancez une recherche en appuyant sur / et entrez le terme de recherche timed out. Killing.
  4. rechercher en arrière en appuyant sur SHIFT+N à plusieurs reprises
  5. la ligne ci-dessous chaque correspondance vous indique quelle application s'est mal comportée: Killing process 1234 (jack_thru) with signal SIGKILL.

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

Bonne chance! :)

16
mzuther

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/d17th

Installer le chien de garde

# pacman -S watchdog

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

# systemctl enable watchdog.service

Démarrez le service pour ne plus voir le message

# systemctl start watchdog.service

Je crée un Gist pour cela https://Gist.github.com/dianjuar/98d02af4050dc2df8ae6f18695d44ca

5
Diego Juliao

J'ai trouvé ici une solution qui fonctionnait 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 Shell et "arrêter maintenant", puis lorsque la machine se rallume, faites un "redémarrage" et le message disparaît et les redémarrages futurs ne se bloquent plus.

J'ai utilisé "Arrêt Sudo maintenant" et le délai de redémarrage a maintenant disparu. Cela semble trop simple, mais cela a fonctionné pour moi (et pour d'autres).

HTH

4
Dennis Cote

Ayant 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 à supprimer une erreur en arrêtant d'abord NetworkManager avant de l'arrêter ou de la désactiver, 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.

Quant à l'autre retard, je n'ai pas réussi. Il semble qu'il soit lié à GDM (Gnome Display Manager), pulseaudio ou dbus. Donc, comme je n'ai pas pu isoler le problème, la seule façon était de définir le DefaultTimeout*Sec=5s entrées dans system.conf comme déjà mentionné dans d'autres articles.

D'autres problèmes pouvant être étudiés sont indiqué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):
├─[email protected]
│ ├─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
4
not2qubit

Comme il s'agit d'un des premiers résultats du moteur de recherche le plus convivial de tous les temps, j'ajouterai ma solution ici: j'utilise Arch Linux avec Gnome Desktop; 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 que Remote Login a été activé dans Settings > Sharing et Sharing a été activé.

Chaque fois que je désactivais cela, mon ordinateur s'arrêtait bien à l'aide du bouton d'arrêt de Gnome.

Étant donné que "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.

2
stueja

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

1
prosoitos

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

Le problème était que Google Chrome s'exécute en arrière-plan et ne se ferme pas lorsque vous éteignez 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é".

enter image description here

Cela l'a résolu pour moi. J'espère que cela aide.

0
ArianJM