A stop job is running for Session c2 of user

Question

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.

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 02 '16 at 16:46
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 02 '16 at 16:49
you can use dpaste.com or any type of paste tool to link your log (emacs have a dpaste plugin you can nstall if you need) — aurelien, Apr 02 '16 at 16:58
@aurelien Here is the output of who: the 1st line thuyenarc pts/0 2016-04-02 22:26 (:0) and the 2nd line thuyenarc pts/1 2016-04-03 00:15 (:0) — dmn, Apr 02 '16 at 17:15
You might get a (temporary) fix by this hack: Create /etc/sysctl.d/50-coredump.conf with contents: kernel.core_pattern=core , ref: https://github.com/systemd/systemd/issues/1615#issuecomment-203507283 — Runium, Apr 02 '16 at 17:44
@aurelien Have you checked loginctl session-status c2 yet? — n.st, Apr 02 '16 at 18:42
https://github.com/systemd/systemd/issues/2691 This may be relevant — Natecat, Apr 02 '16 at 19:18
@n.st yep, but I have just one scope on all machine never two like that — aurelien, Apr 02 '16 at 19:40
@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 02 '16 at 20:01
@aurelien @n.ts I have store loginctl session-status c2 to shutdown-log, but there is nothing in it. So I change loginctl session-status c2 by systemd-cgls. You can see the new log in Addition 2. — dmn, Apr 03 '16 at 01:23
@macnguyen Sorry, I want thinking correctly. Remember how the dmesg output contained messages from after the stop job? The script from "Diagnosing Shutdown Problems" runs after the 90 second timer has ended and the session has been killed forcibly, so of course loginctl can't find it. I don't know a better solution off the top of my head, though... — n.st, Apr 03 '16 at 09:15
For me the Private Internet Access VPN client software turned out to be the cause (on Ubuntu 16.04), as suggested here — , Sep 15 '16 at 08:27
This and the beep are the 2 most annoying things about linux — Santi, Mar 16 '19 at 21:40

score 56 · Answer 1 · edited Jul 22 '19 at 11:04

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

edited Jul 22 '19 at 11:04

Carolus

212
1
10

answered Jul 21 '16 at 09:07

MightyPork

1,222

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 Aug 30 '18 at 09:40
3

I there any job that taking more than 10s to stop? – Jared Chu Dec 25 '18 at 10:22

score 43 · Answer 2 · edited May 11 '19 at 13:52

43

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

wait for the "A stop job is running for Session c2 ..." message to appear on shutdown and reboot after shutdown has completed
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)
start a search by pressing / and enter the search term timed out. Killing.
search backwards by pressing SHIFT+N repeatedly
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! :)

edited May 11 '19 at 13:52

paulie4

103

answered Jan 24 '19 at 21:50

mzuther

572

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 Aug 11 '19 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 Apr 26 '21 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 https://unix.stackexchange.com/questions/159221/how-do-i-display-log-messages-from-previous-boots-under-centos-7) – user000001 Mar 22 '23 at 19:55

Diego Juliao · Answer 3 · 2016-05-20T16:16:52.053

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

edited May 20 '16 at 16:16

answered May 19 '16 at 20:49

Diego Juliao

169

I followed your guide, but it does not solve the problem. Thank you anyway. – dmn Jun 02 '16 at 07: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 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 09:49

score 4 · Answer 4 · answered Feb 13 '18 at 07:15

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

answered Feb 13 '18 at 07:15

Dennis Cote

65
1
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 Jan 31 '19 at 00:04
Worked for me, but it's still unclear why it did. – pstryk Apr 26 '19 at 21:59

score 3 · Answer 5 · answered Dec 13 '17 at 12:36

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

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, Mar 28 '19 at 02:04

score 2 · Answer 6 · answered Apr 25 '18 at 18:55

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.

score 2 · Answer 7 · answered Aug 11 '19 at 10:52

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.

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

This solved it for me. Hope it helps.

answered Aug 11 '19 at 10:52

ArianJM

121

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 Dec 22 '20 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 Feb 08 '22 at 18:50

score 1 · Answer 8 · answered Aug 03 '18 at 09:15

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

score 0 · Answer 9 · answered May 14 '20 at 23:48

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 .

answered May 14 '20 at 23:48

Frank Awadi

1
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 May 15 '20 at 19:04

score 0 · Answer 10 · edited Jul 30 '21 at 13:42

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.

score 0 · Answer 11 · answered Sep 24 '21 at 17:00

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.

A stop job is running for Session c2 of user

11 Answers11

Linked

Related