82

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.

Improve this question
15
  • 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
    Commented Apr 2, 2016 at 16:46
  • 2
    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
    Commented Apr 2, 2016 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
    Commented Apr 2, 2016 at 17:44
  • 1
    github.com/systemd/systemd/issues/2691 This may be relevant
    – Natecat
    Commented Apr 2, 2016 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
    Commented Apr 2, 2016 at 20:01

11 Answers 11

Reset to default
56

A workaround to this problem is to reduce this timeout in /etc/systemd/system.conf down from 90s to for example 10s:

DefaultTimeoutStopSec=10s

and run the following command in terminal after making changes

$ systemctl daemon-reload
Improve this answer
2
  • 24
    this doesn't explain or solve the problem, also waiting for 10s and not even having a clean shutdown is not great at all
    – jcora
    Commented Aug 30, 2018 at 9:40
  • 3
    I there any job that taking more than 10s to stop?
    – Jared Chu
    Commented Dec 25, 2018 at 10:22
43

This problem can have many causes, so specific answers don't work too well. Try this for troubleshooting:

  1. wait for the "A stop job is running for Session c2 ..." message to appear on shutdown and reboot after shutdown has completed
  2. run journalctl -p5 in a terminal and press END to get to the end of the systemd journal (-p5 filters out a lot of garbage)
  3. start a search by pressing / and enter the search term timed out. Killing.
  4. search backwards by pressing SHIFT+N repeatedly
  5. the line below each match tells you which application was misbehaving: Killing process 1234 (jack_thru) with signal SIGKILL.

If it is always the same application, you want to find out what it does and why it isn't stopped at shutdown. Otherwise it could be more complicated to solve the problem, but you might still get a hint or two.

Good luck! :)

Improve this answer
3
  • 1
    Thanks for this correct answer. I used it to find that in my case Fedora 30 "lpf" notifications were the cause, and in lpf-gui deselected Notifications | Enable notifications.
    – vk5tu
    Commented Aug 11, 2019 at 12:16
  • 1
    To jump directly to the end of the journal, do journalctl -e. That's also much faster when the journal is long. To search backwards, use ? instead of /.
    – Matthias Braun
    Commented Apr 26, 2021 at 19:42
  • In my case journalctl only displayed information from the current boot, so I had to do sudo journalctl --boot=-1 -e. (See also unix.stackexchange.com/questions/159221/…)
    – user000001
    Commented Mar 22, 2023 at 19:55
5

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

Improve this answer
5
  • I followed your guide, but it does not solve the problem. Thank you anyway.
    – dmn
    Commented Jun 2, 2016 at 7:22
  • 2
    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
    Commented Dec 11, 2016 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
    Commented Dec 13, 2016 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
    Commented Dec 13, 2016 at 16:52
  • No package named watchdog on OpenSuSE, so this doesn't really help me :(
    – David Faure
    Commented Aug 29, 2017 at 9:49
4

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

Improve this answer
2
  • 13
    Why does this answer have so many upvotes? It didn't work for me, and it gives no clue as to why it should work.
    – Rodrigo
    Commented Jan 31, 2019 at 0:04
  • Worked for me, but it's still unclear why it did.
    – pstryk
    Commented Apr 26, 2019 at 21:59
3

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):
├─[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
Improve this answer
1
  • 2
    This answer at least give us some information on how to find what (of the many possibilities) might be causing the problem on our individual machines. Yet another problem is that after a poweroff or shutdown we cant login to see the actual culprit. systemd needs to log the output from cgls when this problem happens. The best we can do for now is save the output from systemd-cgls and consult it later if/when the hang happens again.
    – duanev
    Commented Mar 28, 2019 at 2:04
2

Since this is one of the first results in the friendliest search engine ever, I will add my solution here: I am using Arch Linux with Gnome desktop; current kernel as of today: 4.16.

I got the message A stop job is running for Session c2 of user ... (1min 30s) whenever Remote Login was activated in Settings > Sharing, and Sharing was activated.

Whenever I disabled that, my computer would shut down nicely using the Gnome shutdown button.

Since "Remote Login" is nothing other than SSH, I assume that not2qubit's answer will also work, because disabling NetworkManager will probably disable SSH as well.

Improve this answer
2

I had this problem for a long time, so I thought I'd share my solution.

The problem was that Google Chrome is running in the background and doesn't close when turning the computer off. So the best solution is to turn that feature off.

  1. Go to Google Chrome's settings.
  2. Click on "Advanced".
  3. Go to "System".
  4. Disable "Continue running background apps when Google Chrome is closed".

enter image description here

This solved it for me. Hope it helps.

Improve this answer
2
  • I experienced the "A stop job is running.." problem when I inadvertently shutdown the OS without realizing Chrome was running - a variation on this Answer, I think
    – rshdev
    Commented Dec 22, 2020 at 18:49
  • This was the problem for me... saved me a lot of time. StackOverflow and other websites should have the buy beer button so you can buy beer for someone who helped you, instead of drinking it yourself to release the stress.
    – Cipi
    Commented Feb 8, 2022 at 18:50
1

Sometimes this can be caused by one app. Remembering changes made just before this starts to happen can be helpful to pinpoint the cause. I had the same issue after installing skypeforlinux-stable-bin on Arch Linux. Closing that app before shutting down solved the problem (I wrote a script to have this done automatically before shutting down).

Improve this answer
0

I started having the same problem when I installed LXDE desktop on Ubuntu 20.04. The system would wait 90 seconds every shutdown or restart: A stop job is running for Session c2 of user ... (1min 30s) Going back to Ubuntu 20.04 default desktop eliminates the problem .

Improve this answer
1
  • 1
    Welcome to U&L. Best to check the questions well, it's a bit more than a downgrade going from arch-linux to ubuntu
    – bu5hman
    Commented May 15, 2020 at 19:04
0

I have the same problem with LXDE on Ubuntu 20.04. I recently upgraded from 18.04. Going back to the default desktop does not work for me. I think I am missing something. In /etc/xdg/lubuntu/lxdm/lxdm.conf, there was a command to start lubuntu (if I recall this correctly):

session=startlubuntu

This command does not exist any more. That means I get dumped into a desktop with pretty wallpaper, a few desktop icons, but no means to launch applications. So I replaced the default with startlxde, which works fine, except for shutdown problem.

Improve this answer
0

I was facing the same issue on a Raspberry PI. I had an application which was started with lxde autostart. I found out that reboot and shutdown would not correctly terminate my application with SIGTERM. This was causing the delay of 1:30min until it was terminated with SIGKILL. My solution was to create a custom reboot and shutdown command/script (alternatively you could create a shell alias). The custom command/script would first terminate my application with SIGTERM using pkill (or kill), wait for a short delay of 2s and then issue the normal reboot or shutdown command.

Improve this answer
0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .