up vote 30 down vote favorite
5

The following message appears almost every time I shutdown my computer:

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

It waits for 1min30s then continues the shutdown process. I follow this systemd shutdown diagnosis guide and get the shutdown-log.txt (I can't paste directly the log here because it's very long). Unfortunately, I don't understand the log by myself. Could anyone help me to find out what makes my system doesn't shutdown properly?

I run Arch Linux with kernel 4.4.5-1-ARCH, my systemd version is 229-3.

Addition 1: I observe that every time I logout, and then shutdown my computer from the login screen, it doesn't get the message A stop job is running.... I tried to logout before shutdown for many times, so I think it doesn't occur by chance. Hope that information could help.

Addition 2: It is always session c2 that causes shutdown hanging. So as @n.st suggest, I looked at Diagnosing Shutdown Problems again and stored loginctl session-status c2 instead of dmesg, but then there is nothing on the shutdown-log.txt. I replaced loginctl session-status c2 by systemd-cgls and got the following log:

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

Any ideas?

Note: After I updated to kernel 4.6.4-1-ARCH and systemd 230-7, the error no longer happened.

share|improve this question
  • Unfortunately the dmesg output you pasted isn't very informative — it shows the WiFi disconnecting when you hit the shutdown button (3048 seconds after system bootup) and then nothing until the 1m30s timer expires and the system continues shutting down (at 3139 seconds). – n.st Apr 2 '16 at 16:46
  • 1
    To check what's running in that ominous session c2 that isn't terminating on its own, use loginctl session-status c2. I'm not sure if you can still switch to a getty during shutdown, but try hitting Ctrl+Alt+F2 when "A stop job is running …" pops up. If that works, you'll get a login prompt and will be able to use loginctl command. If you don't get a login prompt, follow the same steps you used for dmesg, but store the output of loginctl session-status c2 instead. (That's all assuming that it's always "c2" that's hanging, not another session each time.) – n.st Apr 2 '16 at 16:49
  • 1
    You might get a (temporary) fix by this hack: Create /etc/sysctl.d/50-coredump.conf with contents: kernel.core_pattern=core , ref: github.com/systemd/systemd/issues/1615#issuecomment-203507283 – Runium Apr 2 '16 at 17:44
  • 1
    github.com/systemd/systemd/issues/2691 This may be relevant – Natecat Apr 2 '16 at 19:18
  • 2
    @aurelien Is it always c2 that's causing the timer on shutdown? If so, you could follow Diagnosing Shutdown Problems again and store loginctl session-status c2 instead of dmesg. – n.st Apr 2 '16 at 20:01
up vote 22 down vote

It appears you can reduce the timeout in /etc/systemd/system.conf:

DefaultTimeoutStartSec=10s
DefaultTimeoutStopSec=10s
share|improve this answer
  • 4
    You might need to run # systemctl daemon-reload after this, too. – Sparhawk Dec 11 '16 at 23:46
  • 1
    On the computer where I tried this, this led to a failure to boot in the first place, some jobs taking more than 10s. – David Faure Aug 30 '17 at 12:14
up vote 3 down vote

I had the same problem, searching I found a post in a reddit forum of Arch Linux.

Here is the solution that works for me https://www.reddit.com/r/archlinux/comments/4bawf7/a_stop_job_is_running_for_session_c2_of_user/d17th3u

Install watchdog

# pacman -S watchdog

And then start the service at boot:

# systemctl enable watchdog.service

Start the service to don't see the message any more

# systemctl start watchdog.service

I create a gist for this https://gist.github.com/dianjuar/98d02af4050dc2df8ae6f18695d44ca3

share|improve this answer
  • I followed your guide, but it does not solve the problem. Thank you anyway. – macnguyen Jun 2 '16 at 7:22
  • 1
    Are there any other implications to this fix? Apparently watchdog will hardware reset the system if it lags or fails other tests. So when the timeout in the question occurs, watchdog will reset the computer. I wonder if the system would shutdown more cleanly if we just reduced the timeout as per the other answer. I also wonder if watchdog would force a reset in other, unwanted situations. – Sparhawk Dec 11 '16 at 23:44
  • I read your man page. I think that watchdog prevent the reset telling the linux kernel that everything is OK, – Diego Juliao Dec 13 '16 at 16:52
  • > It opens /dev/watchdog, and keeps writing to it often enough to keep the kernel from resetting, at least once per minute. – Diego Juliao Dec 13 '16 at 16:52
  • No package named watchdog on OpenSuSE, so this doesn't really help me :( – David Faure Aug 29 '17 at 9:49
up vote 1 down vote

I found a solution here that worked for me with Debian 9 on vbox. I was getting the typical 120 sec delay on shutdown or restart.

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

Do just as Ironman says:

The solution is to open shell and "shutdown now" then when the machine comes back on then do a "reboot" and the message goes away and future reboots do not hang anymore.

I used "sudo shutdown now" and the restart delay is now gone. Seems too simple, but it worked for me (and others).

HTH

share|improve this answer
up vote 0 down vote

Having had a similar issue on Kali [2017.01], with alternating logout delay displayed by:

"A stop job is running for Session c1 of user Debian-gdm"

"A stop job is running for User manager for UID 132"

I managed to rid one error by first stopping NetworkManager before shutdown or disable it, with:

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

This should probably be fixed or put in another way when rebooting.

As for the other delay, I have not been successful. It seem that it may be related to GDM (Gnome Display Manager), pulseaudio or dbus. So since I was not able to isolate the problem, the only way was to set the DefaultTimeout*Sec=5s entries in system.conf as already mentioned in other posts.

Other issues that may be investigated are shown 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.

and:

# 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
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.