it-swarm.com.de

Für die Sitzung c2 des Benutzers wird ein Stoppjob ausgeführt

Die folgende Meldung wird fast jedes Mal angezeigt, wenn ich meinen Computer herunterfahre:

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

Es wartet 1 Minute 30 Sekunden und setzt dann den Herunterfahrvorgang fort. Ich folge dieser Anleitung zur Diagnose des Herunterfahrens des Systems und erhalte das shutdown-log.txt (Ich kann das Protokoll hier nicht direkt einfügen, da es sehr lang ist). Leider verstehe ich das Protokoll selbst nicht. Könnte mir jemand helfen, herauszufinden, warum mein System nicht richtig heruntergefahren wird?

Ich führe Arch Linux mit dem Kernel 4.4.5-1-Arch Aus, meine systemd Version ist 229-3.

Ergänzung 1: Ich beobachte, dass jedes Mal, wenn ich mich abmelde und dann meinen Computer vom Anmeldebildschirm herunterfahre, die Meldung A stop job is running.... Ich habe viele Male versucht, mich vor dem Herunterfahren abzumelden, daher denke ich, dass dies nicht zufällig geschieht. Hoffe, dass Informationen helfen könnten.

Ergänzung 2: Es ist immer Sitzung c2, die das Herunterfahren verursacht. Wie @ n.st vorschlägt, habe ich mir Diagnose von Problemen beim Herunterfahren erneut angesehen und loginctl session-status c2 Anstelle von dmesg gespeichert, aber dann befindet sich nichts auf dem shutdown-log.txt. Ich habe loginctl session-status c2 Durch systemd-cgls Ersetzt und das folgende Protokoll erhalten:

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

Irgendwelche Ideen?

Hinweis: Nachdem ich auf Kernel 4.6.4-1-Arch Und systemd 230-7 Aktualisiert habe, ist der Fehler nicht mehr aufgetreten.

67
macnguyen

Eine Problemumgehung für dieses Problem besteht darin, dieses Zeitlimit in /etc/systemd/system.conf von 90s auf zum Beispiel 10s:

DefaultTimeoutStopSec=10s

führen Sie den folgenden Befehl im Terminal aus, nachdem Sie Änderungen vorgenommen haben

$ systemctl daemon-reload
46
MightyPork

Dieses Problem kann viele Ursachen haben, sodass bestimmte Antworten nicht gut funktionieren. Versuchen Sie dies zur Fehlerbehebung:

  1. warten Sie, bis beim Herunterfahren die Meldung "Ein Stoppjob wird für Sitzung c2 ausgeführt ..." angezeigt wird, und starten Sie den Computer nach Abschluss des Herunterfahrens neu
  2. führen Sie journalctl -p5 in einem Terminal aus und drücken Sie END, um zum Ende des systemd-Journals zu gelangen (-p5 filtert viel Müll heraus).
  3. starten Sie eine Suche durch Drücken von / und geben Sie den Suchbegriff timed out. Killing. ein.
  4. suchen Sie rückwärts, indem Sie wiederholt SHIFT+N drücken
  5. die Zeile nten Jede Übereinstimmung zeigt an, welche Anwendung sich schlecht benommen hat: Killing process 1234 (jack_thru) with signal SIGKILL.

Wenn es sich immer um dieselbe Anwendung handelt, möchten Sie herausfinden, was sie tut und warum sie beim Herunterfahren nicht gestoppt wird. Andernfalls könnte es komplizierter sein, das Problem zu lösen, aber Sie erhalten möglicherweise immer noch ein oder zwei Hinweise.

Viel Glück! :) :)

16
mzuther

Ich hatte das gleiche Problem, als ich suchte, fand ich einen Beitrag in einem reddit-Forum von Arch Linux.

Hier ist die Lösung, die für mich funktioniert https://www.reddit.com/r/archlinux/comments/4bawf7/a_stop_job_is_running_for_session_c2_of_user/d17th

Installieren Sie den Watchdog

# pacman -S watchdog

Und dann starten Sie den Dienst beim Booten:

# systemctl enable watchdog.service

Starten Sie den Dienst, um die Nachricht nicht mehr zu sehen

# systemctl start watchdog.service

Ich erstelle ein Gist dafür https://Gist.github.com/dianjuar/98d02af4050dc2df8ae6f18695d44ca

5
Diego Juliao

Ich habe hier eine Lösung gefunden, die für mich mit Debian 9 auf vbox funktioniert hat. Ich habe die typische Verzögerung von 120 Sekunden beim Herunterfahren oder Neustart erhalten.

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

Mach genau das, was Ironman sagt:

Die Lösung besteht darin, Shell zu öffnen und "jetzt herunterzufahren". Wenn der Computer wieder eingeschaltet wird, führen Sie einen "Neustart" durch, und die Meldung wird ausgeblendet, und zukünftige Neustarts hängen nicht mehr.

Ich habe "Sudo shutdown now" verwendet und die Neustartverzögerung ist jetzt weg. Scheint zu einfach, aber es hat bei mir (und anderen) funktioniert.

HTH

4
Dennis Cote

Nach einem ähnlichen Problem bei Kali [2017.01] mit abwechselnder Abmeldeverzögerung angezeigt durch:

"Für Sitzung c1 des Benutzers Debian-gdm wird ein Stoppjob ausgeführt."

"Für User Manager für UID 132 wird ein Stoppjob ausgeführt."

Ich habe es geschafft, einen Fehler zu beheben, indem ich zuerst NetworkManager vor dem Herunterfahren gestoppt oder deaktiviert habe, mit:

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

Dies sollte beim Neustart wahrscheinlich behoben oder auf andere Weise festgelegt werden.

Was die andere Verzögerung betrifft, war ich nicht erfolgreich. Es scheint, dass es mit GDM (Gnome Display Manager), pulseaudio oder dbus zusammenhängt. Da ich das Problem nicht eingrenzen konnte, bestand die einzige Möglichkeit darin, das DefaultTimeout*Sec=5s Einträge in system.conf wie bereits in anderen Beiträgen erwähnt.

Weitere Probleme, die untersucht werden können, sind aufgeführt in:

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

und:

# 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

Da dies eines der ersten Ergebnisse in der freundlichsten Suchmaschine aller Zeiten ist, werde ich hier meine Lösung hinzufügen: Ich verwende Arch Linux mit Gnome-Desktop. aktueller Kernel ab heute: 4.16.

Ich habe die Meldung A stop job is running for Session c2 of user ... (1min 30s) erhalten, wenn Remote Login In Settings > Sharing Aktiviert wurde und Sharing aktiviert wurde.

Immer wenn ich das deaktivierte, wurde mein Computer mit der Gnome-Schaltfläche zum Herunterfahren ordnungsgemäß heruntergefahren.

Da "Remote Login" nichts anderes als SSH ist, gehe ich davon aus, dass die Antwort von not2qubit auch funktioniert, da durch Deaktivieren von NetworkManager wahrscheinlich auch SSH deaktiviert wird.

2
stueja

Manchmal kann dies durch eine App verursacht werden. Das Erinnern an Änderungen, die unmittelbar vor Beginn vorgenommen wurden, kann hilfreich sein, um die Ursache zu ermitteln. Ich hatte das gleiche Problem nach der Installation von skypeforlinux-stable-bin unter Arch Linux. Das Schließen dieser App vor dem Herunterfahren löste das Problem (ich habe ein Skript geschrieben, das dies vor dem Herunterfahren automatisch ausführt).

1
prosoitos

Ich hatte dieses Problem lange Zeit und dachte, ich würde meine Lösung teilen.

Das Problem war, dass Google Chrome im Hintergrund ausgeführt wird und beim Ausschalten des Computers nicht geschlossen wird. Die beste Lösung besteht also darin, diese Funktion auszuschalten.

  1. Gehen Sie zu den Einstellungen von Google Chrome.
  2. Klicken Sie auf "Erweitert".
  3. Gehen Sie zu "System".
  4. Deaktivieren Sie "Hintergrund-Apps weiter ausführen, wenn Google Chrome ist geschlossen").

(enter image description here

Das hat es für mich gelöst. Ich hoffe es hilft.

0
ArianJM