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 /:
  ├─   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 2 '16 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 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

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


and run the following command in terminal after making changes

$ systemctl daemon-reload
  • 21
    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 9:40
  • 2
    I there any job that taking more than 10s to stop? – Jared Chu Dec 25 '18 at 10:22

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

  • 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
  • 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 at 19:42

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

  • I followed your guide, but it does not solve the problem. Thank you anyway. – macnguyen Jun 2 '16 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 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

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.


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


  • 11
    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 0:04
  • Worked for me, but it's still unclear why it did. – pstryk Apr 26 '19 at 21:59

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.


# systemd-cgls -u user-132.slice

Unit user-132.slice (/user.slice/user-132.slice):
│ ├─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)
  ├─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
  • 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 Mar 28 '19 at 2:04

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.


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


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.

  • 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

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 .

  • 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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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