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'é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.

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

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! :)

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

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

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

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.

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).

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é".

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