System hangs at reboot/shutdown - Arch Linux

[prescott66]

Hi.
When i try to shutdown/reboot arch linux, my system hangs to cca 90 seconds and then shutdown or reboot.
I have created bug report at arch's bugzilla, but there is no one, who can find the problem.
It looks like there is problem with systemd, because after update to v227 issue is fixed for few reboots, then is back.
PLEASE take a look at my logs in bug report. Maybe you will find problem:

https://bugs.archlinux.org/task/46709

[prescott66]

Now i get two jobs, that are waiting to stop at shutdown:
1.)Session c1 of user
2.)User manager for UID 1000

[dvdhrm]

If your session is not stopped at shutdown, it's very likely due to a program in your session being stuck. Please try logging out of your session and then check via a different user which programs are still running in that session. The systemd-cgls tool might come in handy.

[prescott66]

Here is my output of systemd-cgls command:

https://drive.google.com/file/d/0B7IVEEF2578ra2xGUFlzSDVmbkE/view?usp=sharing

[elkrejzi]

Apparently I'm not the only one with this issue. I ran into it too. See also

http://lists.freedesktop.org/archives/systemd-devel/2016-January/035619.html

Hope it gets resolved soon.

[Potomac]

I have the same bug, a message "A stop job is running for Session c2 for user...." and a delay of 90 seconds,

I use archlinux, systemd 229-3

[ongun-kanat]

Same as @Potomac here. Ver. 229-3

[diegoviola]

Same problem here on systemd 229 (archlinux)

[nagyf]

I have the same problem, systemd 229-3, arch linux. How can we check what program hangs?

[ongun-kanat]

@nagyf I don't think it's about a program refuses to terminate but systemd guys screwed user services things so that the user daemon of systemd fails to shutdown properly.

[ghost]

I approve, have similar problem on Arch with systemd 229-3. It's definately not connected with desktop manager but only systemd :( I'm waiting for fix couse right now almost every shutdown seems to be the weakest part of my system.

[meradoou]

I have same problem on Archlinux

[M-Tarasov]

I can also confirm the issue with systemd 229-3 on Arch Linux

[varlesh]

Confirm this

[cross1983]

I have the same issue periodically (not each time). So i confirm this issue.

[manjarqo]

I confirm the issue too

[virpool]

Confirm this issue too.

[lynxthecat]

Confirmed Archlinux. Something about "Session c1 of user" and hangs without shutting down properly. I can still Ctrl-Alt-F but otherwise unresponsive.

[GeorgeTG]

I have this issue too, but only on my desktop. Version 229-3 Arch Linux. Happens randomely at reboot/shutdown. "Session c2 of user" and i get a 90 sec timeout. Any way we can help or provide more info on this ?

[bunkbail]

I'm using systemd 229-3 Arch and I can confirm this. Its already continuing hanging on shutdown for about 2 weeks now.

EDIT: A workaround here. I'm using Gnome, loging out current seesion before reboot/shutdown works for me. But it still doesn't remedy the problem.

[hexagonal-sun]

+1 on Arch Linux.

[firekage]

I can confirm it. In fact, i have this for a long time - Arch linux. What is strange, i don't have it on laptop machine and netbook machine. On all of them, i have nearly exacly the same programs, and apps but only on desktop i have conky.

BTW - this "bug" is not only true for 229-3. I had previous version with the same bug.

Edit: after yesterday updates, my laptop and netbook machines have the same behaviour during shutdown.

[benjarobin]

I have done an analyze here #2691 (comment) And I think I found the root cause of the problem. The solution is not that easy, I have got an idea how to solve the problem (but I don't like it), I thing @poettering will have a better idea

[Potomac]

there is a workaround found by Ebiggers :

just create a file "/etc/sysctl.d/50-coredump.conf" with the following contents:

kernel.core_pattern=core

then after a reboot this bug will never occur

[bakteria1]

Same issue here

[Potomac]

despite the workaround found by Ebiggers I still have the bug ( "a stop job for session C2 user" )

it's a random bug, for example it can occur after 10 reboots ( that's why I thought it was solved, we need to test with a lot of reboot/shutdown, the bug will be considered as solved only when no bug occurs after at least 10~15 reboots )

[varlesh]

Yes, random. Sometime reboot now, sometime reboot wait 90 sec. I kill plasmashell and other processes change DM (lightdm, sddm, slim) - this not solved problem.

[adeleglise]

Hi all,
I'm facing the same issue.

[molecularresearcher]

Thank you very much!
I did how Potomac described and the problem is solved.

ISamsung NC10 and Acer Aspire 7739 - and in both Arch Linux Kernel 4.4

[kyawthusoe45]

Systemd 215-17, Debian Jessie: confirm this.

[ghost]

I have this problem with Mint 18.1. It's driving me crazy. I've tried all sorts of workaround and none of them - at least fully - work. For I still have the problem, at least when using ethernet as against wifi. The problem means I have to hard reset my machine, which can't be good for it. This problem takes us back to the bad old days of Linux when basically nothing worked without hacks and prayer.

EDIT: It seems no-one is assigned to this bug. Why?

[grossws]

I have similar issue on ArchLinux (linux 4.11.2-1-ARCH, systemd 232-8, plamsa-desktop 5.9.5-1, sddm 0.14.0-2).

It seems that either kded5 or sddm is an offending process. On shutdown sequence sddm tries to stop both X server and plasma/kde (which is run under sddm-helper) and X stops before kded5 which somehow leads to latter to ignore SIGTERM.

May 30 00:35:05 wahnsinn sddm[687]: Display server stopping...
May 30 00:35:05 wahnsinn sddm-helper[5686]: [PAM] Starting...
May 30 00:35:05 wahnsinn sddm-helper[5686]: [PAM] Authenticating...
May 30 00:35:05 wahnsinn sddm-helper[5686]: [PAM] returning.
May 30 00:35:05 wahnsinn systemd[1]: Stopped Manage swap spaces on zram, files and partitions..
May 30 00:35:07 wahnsinn sddm[687]: Display server stopped.
May 30 00:35:07 wahnsinn sddm[687]: Running display stop script  "/usr/share/sddm/scripts/Xstop"
May 30 00:35:07 wahnsinn sddm[687]: QProcess: Destroyed while process ("/usr/lib/sddm/sddm-helper") is still running.
May 30 00:35:07 wahnsinn systemd[1]: Stopped Simple Desktop Display Manager.
May 30 00:36:32 wahnsinn systemd[1]: session-c2.scope: Stopping timed out. Killing.
May 30 00:36:32 wahnsinn systemd[1]: session-c2.scope: Killing process 1373 (kded5) with signal SIGKILL.
May 30 00:36:32 wahnsinn systemd[1]: Stopped Session c2 of user gross.
May 30 00:36:32 wahnsinn systemd[1]: session-c2.scope: Unit entered failed state.

See also FS#46585 (Arch bugtracker)

[osho741]

My system with Openbox/Tint2 on kernel 4.11.2-1_ARCH just freezes when doing reboot from terminal. If I roll back to 4.10.17 it is able to reboot fine.

[smcv]

There are many reasons why a system might hang during reboot/shutdown. It is a symptom, not a cause. If you do not have evidence that the root cause of your system hang is the same as the root cause of the system hang experienced by the initial reporter of this issue, then please do not reply to this issue.

If you see the same symptom for a different reason, then nothing that has been said on this issue report is going to help you, and anything you say on this issue report is just going to make it even more confusing to a reader.

Please contact your distribution vendor (Arch Linux, Ubuntu/Canonical, Mint, etc.) for initial support. If you have evidence that your issue is caused by systemd (not to be confused with a bug merely involving systemd) then you can report that as a separate bug, with a more specific description based on that evidence.

For example, the details provided by @grossws seem to indicate a bug in either kded5, sddm, or the systemd units provided with sddm. That is probably not a bug in systemd and will probably not be fixed by changing systemd, so this is the wrong place to ask for a solution.

It seems no-one is assigned to this bug. Why?

Here are some reasons why assigning a developer to work on this issue would be counterproductive:

1. Because the issue was closed in 2016. Closed issues are not worked on. If you have evidence of a bug in systemd, please open a new issue to represent it, with a more specific title and description than this one, and do not mix it up with everything else that has been said in this thread.

2. Because there does not seem to be any particular evidence that any of the various problems that different people are experiencing are bugs in systemd, as opposed to bugs in particular services that they are running. Bugs in pieces of software outside systemd are not solved by changing systemd, they are solved by changing the other piece of software.

3. Because even if some or all of the problems reported in this comment thread were caused by bugs in systemd, no single volunteer is going to want to take responsibility for fixing a series of different bugs (some of which might be bugs in systemd, some of which are almost certainly not) that are getting mixed into this issue thread. That would be an endless task - by the time one had been solved, another would likely have been reported, because the title of this issue thread is so general that it could describe all sorts of different root causes. Again, if you have evidence of a bug in systemd, please open a new issue to represent it, and do not mix it up with everything else that has been said in this thread.

[ghost]

Dear @smcv

• Thank you for your explanations.

• A combination of several bits of hackery seem to have solved the problem for me. If the problem recurrs I will open a new bug report.

• It seems to me that (contrary to your point 2) the number of contributions of this thread is prima facie evidence of a problem - perhaps qua full-blown bug, perhaps qua something that is encouraging software writers to code their services wrongly - with systemd.

[audiomuze]

got the same thing happening here, every time shut down my laptop. Running Arch 4.11.7-1-ARCH

[smcv]

@audiomuze Please contact your distribution vendor (in your case Arch Linux?) for initial support. If there is evidence that your issue is caused by systemd (and not a result of a bug in some other component), please open a separate bug report with full details of the symptoms and evidence, including relevant log messages and version numbers.

The title of this issue is a symptom, not a cause; there are many things that could be causing it (some of them would be systemd bugs, and some of them would not). If everyone whose system hangs during shutdown keeps adding comments to this closed issue report, then we are never going to be able to disentangle which bug reporter was suffering that symptom as a result of which root cause.

@poettering, perhaps it would be worthwhile to close the comments on this issue?

[poettering]

@poettering, perhaps it would be worthwhile to close the comments on this issue?

Uh, I am a bit afraid of the reddit firestorm this would likely result in...

[ElLocoNutz]

@smcv So basically you hear hoofbeats and think zebras

[adrinjalali]

@smcv If several people, many of whome are tech-savy enough to have installed and working with archlinux, and wait and read the message they see on their screen, and then come back and search for the issue tying to report/fix/help in that regard, are commenting on the same issue here because of the same "symptom" they observe, maybe you should open an issue for your piece of software to give a more helpful message.

[tsdh]

Same problem on a current Arch laptop (since ages, I think), i.e., it is waiting for a stop job of User Manager for UID 1000 (which is my user). But now I had the time to debug the issue. After my user (with uid 1000) logged out, I checked systemd-cgls and there's still

│ └─user-1000.slice
│   └─user@1000.service
│     ├─init.scope
│     │ ├─2140 /usr/lib/systemd/systemd --user
│     │ └─2141 (sd-pam)
│     └─tracker-store.service
│       └─2471 /usr/lib/tracker/tracker-store

So do I see it correctly that in my case, GNOME's desktop search (Tracker) is the faulty process which doesn't properly terminate when being sent a SIGTERM followed by a SIGHUP and I should report a bug for that?

[silliwretep]

This is caused by a kernel driver failing on shutdown.
The culprit can be found by methodically using modprobe -r to remove a specific driver and then shutting down.
If removing that driver before shutdown allows the system to proceed normally, that driver is likely the culprit.

If you have custom drivers on the system, the shutdown script for that driver system should contain lines to modprobe -r the drivers used prior to shutdown or reboot. This ensures the bad driver is unloaded before shutdown.

It may be good to somehow get test of what driver is currently being closed/called for debug purposes. Anyone know if that possible with kernel debugging enabled?

[kareliot]

@tsdh thanks for this. I have the exact same thing showing up when running systemd-cgls after logging out with user uid 1000.
So tracker does seem to cause the problem. Have you found out anything else?

[tsdh]

@kareliot Nope, nothing new from my side. Didn't have the time to debug any more, and since the issue is just on one machine, it hasn't bothered me enough.

[ulises-jeremias]

I have same problem on Archlinux

[kareliot]

I have opened a bug report about the tracker.store.system issue in the gnome bug tracker:
https://bugzilla.gnome.org/show_bug.cgi?id=793027#c2
Someone has already started debugging, but I have not had time to see if I can reproduce their findings.

[ghost]

I have the same problem - but on Linux Mint.

[stueja]

For me (Arch Linux, Gnome desktop) the issue resolves whenever I deactivate Settings > Sharing > Remote Login. Hope that helps?

[ghost]

Thanks stueja, but my own workaround is to allow my Internet connection to persist after log off.

[kevinxucs]

Still happens on Debian Testing

[FabianInostroza]

@kevinxucs It seems to be related to dleyna-renderer, I found the following on my shutdown log:

jun 02 04:34:29 debian systemd[1862]: dbus.service: State 'stop-final-sigterm' timed out. Killing.
jun 02 04:34:29 debian systemd[1862]: dbus.service: Killing process 14329 (dleyna-renderer) with signal SIGKILL.
jun 02 04:34:29 debian systemd[1862]: dbus.service: Killing process 14330 (gmain) with signal SIGKILL.
jun 02 04:34:29 debian systemd[1862]: dbus.service: Failed with result 'timeout'.

Also found the following bug reports:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868951
intel/dleyna-renderer#164

You could try to uninstall dleyna-renderer and see if the problem goes away.

EDIT: at shutdown the message shown in screen is "Stopping User Manager for...", the message "Stopped User Manager..." is shown after systemd kills dleyna-renderer.

[kevinxucs]

@FabianInostroza Thanks for pointing me the bug, but I am not sure I have dleyna-render installed.

The solution for me is to switch from gdm to lightdm, so I guess something related with gdm for my case

[chuchana]

In my case, this problem was caused by a service that was not required.

Here's how I fixed it. Maybe it can help someone:

1. Find the problem: journalctl | grep -i shutdown
   ➡︎ […] systemd[1]: Failed to start Disable brcmfmac kernel module […]
2. The driver is not installed: lsmod | grep brcmfmac returns nothing
3. Find the service: systemctl list-unit-files | grep brcm
   ➡︎ remove-brcmfmac.service enabled
4. Disable the service: systemctl disable remove-brcmfmac.service
5. Find the file location: systemctl status remove-brcmfmac.service
   ➡︎ […] Loaded: loaded (/etc/systemd/system/remove-brcmfmac.service; […]
6. Delete the file: sudo rm /etc/systemd/system/remove-brcmfmac.service