Systemd 208: hang on reboot

erm67 · 2013-11-24 15:14:54

WonderWoofy wrote:

Add "Before=basic.target" to dbus.service.

I was having exactly the same problem, and tried this workaround but it didn't fixed it, however it gave a strange error on startup like "not starting dbus to break dependency cycle" or something like that, so I thought that this was indeed part of the problem. I also had the errors with networkmanager being already started so I thought maybe the problem is gdm, the user mentioned in the log as hanging is gdm, so I modified
/usr/lib/systemd/system/gdm.service this way:

[Unit]
Description=GNOME Display Manager
Conflicts=getty@tty1.service plymouth-quit.service
After=systemd-user-sessions.service getty@tty1.service plymouth-quit.service dbus.service

and the problem disappeared, it takes a little longer to boot however, I had the same problem with lighdm as well so probably is something related to all login managers.

EDIT nope the problem did not disappear, apparently it doesn't hang at every boot.

Last edited by erm67 (2013-11-24 15:37:08)

WonderWoofy · 2013-11-24 21:10:23

@erm67, yeah, it seemed to have helped, but certainly did not fix the situation. It would hang less frequently with that ordering, but I would still get it from time to time. The breaking of the dependency cycle is to be expected from this workaround, as it is intended to apply to the shutdown process and not necessarily the start process (which continued to work fine).

I did run systemd-git for a bit before all the massive changes for the mvoe to kdbus, and it did seem fixed. But then again, putting that dbus.socket ordering in there seems to help but not solve. So maybe I just didn't run it for long enough to actually run into a hang.

erm67 · 2013-11-25 16:52:41

Now I am using:

Before=graphical.target

in /usr/lib/systemd/system/dbus.service

and it works even better, still it hangs sometimes but at least not always. I think I will put again systemd in debug mode and retest this evening.

At shutdown before/after rules are applied in reverse, so this means dbus will be stopped after the graphical target has been completely shut down. But also NetworkManager uses dbus, so maybe it might be that the problem .....

Last edited by erm67 (2013-11-25 16:56:39)

WonderWoofy · 2013-11-25 18:11:21

The ordering should inherently place the graphical.target after the dbus.service anyway. Though this might be getting shut down because it is socket activated.

I wonder though, if it wouldn't be better to have it "Before=multi-user.target" as this would also cover the cases for users who don't use the graphical.target at all (non login manager users). I guess it would possibly also benefit any graphical.target user who happens to also use the TTY from time to time...

I'm going to throw this into the dbus.service and see how things go.

erm67 · 2013-11-25 19:10:38

In theory, in practice debug shows that dbus is always shut down before the user services, than the process hangs for a while. It also almost always started after NetworkManager.
http://freedesktop.org/wiki/Software/systemd/Debugging/
follow this guide:

Shutdown Completes Eventually
If normal reboot or poweroff work, but take a suspiciously long time, then
boot with the debug options:
systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M enforcing=0
save the following script as /lib/systemd/system-shutdown/debug.sh and make it executable:
#!/bin/sh
mount -o remount,rw /
dmesg > /shutdown-log.txt
mount -o remount,ro /
reboot
Look for timeouts logged in the resulting file shutdown-log.txt and/or attach it to a bugreport.

shutdown a couple of times and look at the log. Don't forget that shutdown-log.txt is the log of the previous run (it is written at sutdown). Running in debug mode slows terribly down my computer.

The last 4 boots went fine for me, it hung only once after a kernel oops in rpc_gssd (different problem)....

Last edited by erm67 (2013-11-25 19:16:38)

Rexilion · 2014-01-01 12:17:54

Happy new year everyone!

Sorry for reopening this thread. I think I have the same issue here. Any suggestions? I'm thinking of just waiting for a fix, or did it already land in stable?

jghodd · 2014-01-07 07:02:34

The fix will be included in the next release of systemd, confirmed here: https://projects.archlinux.org/svntogit … es/systemd

The bug: https://bugzilla.redhat.com/show_bug.cgi?id=1027478
The patch: http://cgit.freedesktop.org/systemd/sys … 0035d4743a

[Edit: I have a patched version of systemd for the x86_64 platform here: http://sourceforge.net/projects/bluesta … /download]

Last edited by jghodd (2014-01-07 07:10:03)

WonderWoofy · 2014-01-07 07:16:58

jghodd wrote:

The fix will be included in the next release of systemd, confirmed here: https://projects.archlinux.org/svntogit … es/systemd

I don't think this is the same issue. This thread is about the actual shutdown part that hangs, not the boot sequence.

Arch Linux

#51 2013-11-24 15:14:54

Re: Systemd 208: hang on reboot

#52 2013-11-24 21:10:23

Re: Systemd 208: hang on reboot

#53 2013-11-25 16:52:41

Re: Systemd 208: hang on reboot

#54 2013-11-25 18:11:21

Re: Systemd 208: hang on reboot

#55 2013-11-25 19:10:38

Re: Systemd 208: hang on reboot

#56 2014-01-01 12:17:54

Re: Systemd 208: hang on reboot

#57 2014-01-07 07:02:34

Re: Systemd 208: hang on reboot

#58 2014-01-07 07:16:58

Re: Systemd 208: hang on reboot

Board footer