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.
]]>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]
]]>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?
]]>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)....
]]>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.
]]>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 .....
]]>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.
]]>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.
]]>I am starting to think you have the same problem as me, because the errors you're getting are very similar in your shutdown log. Except I get them in my boot up log which means my system never boots up. Chroot is useless for me because systemd doesn't allow chroot.
Sorry? Why would systemd not allow chroot?
]]>I am starting to think you have the same problem as me, because the errors you're getting are very similar in your shutdown log. Except I get them in my boot up log which means my system never boots up. Chroot is useless for me because systemd doesn't allow chroot.
]]>What's the ModemManager1 stuff about?
It's needed by NetworkManager if you are using a modem (cell phone in my case).
I'm not using it right no so it should be turned off. When I disabled and stopped it manually then my laptop shuts down immediately but now it still hangs.
Setted watchdog to 15sec will see if it wold help.
]]>Can somebody point me in the direction of older systemd files?
here's the most general method
https://wiki.archlinux.org/index.php/Do … _a_package
I have systemd back to 204 in my pacman cache
ls /var/cache/pacman/pkg/sys
sysfsutils-2.1.0-8-x86_64.pkg.tar.xz systemd-208-1-x86_64.pkg.tar.xz
sysstat-10.1.6-2-x86_64.pkg.tar.xz systemd-sysvcompat-204-3-x86_64.pkg.tar.xz
sysstat-10.1.7-1-x86_64.pkg.tar.xz systemd-sysvcompat-207-3-x86_64.pkg.tar.xz
systemd-204-3-x86_64.pkg.tar.xz systemd-sysvcompat-207-5-x86_64.pkg.tar.xz
systemd-207-3-x86_64.pkg.tar.xz systemd-sysvcompat-208-1-x86_64.pkg.tar.xz
systemd-207-5-x86_64.pkg.tar.xz sysvinit-tools-2.88-11-x86_64.pkg.tar.xz
I'm not seeing which specific service is takiing a long time to stop
It has been reported that the user@0.service is hanging. The newest versions of systemd use the user@.service to start systemd --user for each user that logs in. Apparently, the issue arises from dbus being stopped before this service can stop, resulting it it sending messages to a destinationthta no longer exists...
]]>