Description of problem: A system with systemd does not power off Version-Release number of selected component (if applicable): Name : systemd Relocations: (not relocatable) Version : 0 Vendor: Fedora Project Release : 0.4.20100614git393034.fc14 Build Date: Mo 14 Jun 2010 12:31:07 Linux proprietary.local 2.6.34-40.fc14.i686 #1 SMP Wed Jun 16 15:33:07 UTC 2010 i686 i686 i386 GNU/Linux How reproducible: Always Steps to Reproduce: 1. Install systemd in rawhide 2. Add systemd to your kernel line in grubs menu.lst (init=/bin/systemd) 3. Start your system 4. Shut down your system Actual results: System stops with a message saying something like "force-stop" Expected results: System shuts down cleanly Additional info: I need to get the whole error
The message is something like: "Not stopping monitoring. This is a dangerous operation. Use force-stop."
Yes. But the situation improved after some updated. Now it cycles through a couple of unmount cycles and shuts down.
Doesn't work for me yet, even the latest systemd 2 version. It did not shut down, i waited for 10 minutes.
Could you please retry with v3? The umount thing is known and needs to be fixed in the initscripts package, see bug 612789.
(In reply to comment #1) > The message is something like: > "Not stopping monitoring. This is a dangerous operation. Use force-stop." This is a message from /etc/init.d/lvm2-monitor. It does not show up under upstart because lvm2-monitor uses a trick: ... WARN=1 ... case "$1" in ... stop) test "$runlevel" = "0" && WARN=0 test "$runlevel" = "6" && WARN=0 stop ... And I suppose $runlevel does not make sense in the world of systemd.
On a kvm rawhide system with systemd-3-3.fc14.x86_64.rpm I hang after Stopping crond: [ OK ] and the the not stopping monitoring message.
*** Bug 615796 has been marked as a duplicate of this bug. ***
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle. Changing version to '14'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Adding lvm2 maintainer in case he has any input on this. I saw the same symptom trying to shut down the first time I tried with systemd, haven't tried many more times to see if it still happens. If this is reproducible on a fresh Rawhide install with systemd (whenever we can manage to do such a thing...), it's likely an Alpha blocker. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
*** Bug 619927 has been marked as a duplicate of this bug. ***
It goes like this - lvm2-monitor refuses to stop, therefore it keeps /var/lock/subsys/lvm2-monitor and returns 1. - halt.service requires killall.service, so "/etc/init.d/killall start" is run. - /etc/init.d/killall sees a file is still present in /var/lock/subsys and tries to stop the corresponding service. The lvm2-monitor initscript fails again with error code 1. - /etc/init.d/killall does not set its own exit code. It propagates the exit code 1 from the lvm2-monitor initscript. - systemd sees killall.service failed. - systemd marks halt.service as failed too and stops processing. Possible fixes in 3 components: - lvm2 - could stop doing its layering violation (which changing the behaviour of the initscript based on the current runlevel is). - initscripts - could explicitly exit 0 at the end of /etc/init.d/killall - systemd - could use Wants instead of Requires for the dependency halt.service -> killall.service
Well, there's no reason killall should arbitrarily return the return code of the last thing it tries to stop. So, an 'exit 0' is appropriate there. http://git.fedorahosted.org/git/?p=initscripts.git;a=commitdiff;h=677fbac75b7517a4e20a65d555e3d33c37af79a4
And yes, the typo in the above commit is fixed upstream.
I get similar when running F14-branched in a VirtualBox -- the screen just stays black, and it doesn't shut down; I still have a mouse pointer, it seems, though. I end up having to do a hard reset
OK, so I figure this may now be closed with Bill's fix?
Bill's patch is only in upstream. An update of initscripts is needed.
I see this bug in Alpha RC2. It's clearly a Beta blocker: "The desktop's offered mechanisms for shutting down, logging out and rebooting must work" it'd be nice to fix it for Alpha, or else we'll get just a ton of reports. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
*** Bug 622493 has been marked as a duplicate of this bug. ***
initscripts-9.16-2.fc14 has been submitted as an update for Fedora 14. http://admin.fedoraproject.org/updates/initscripts-9.16-2.fc14
initscripts-9.16-2.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 623247 has been marked as a duplicate of this bug. ***
AFAICT this is still utterly broken in rawhide. systemd-11-1.fc15 initscripts-9.21-5.fc15 After 'poweroff', 'shutdown -h now', 'reboot' or 'shutdown -r now' the whole system goes down to that extent that is not possible to login anymore and rsyslogd is stopped (the last recorded line in /var/log/messages says that) and not much happens after this point. On screen one can find something in this style: Unit reboot.service entered failed state. followed up by a message from audit: ... comm="reboot", exe="/bin/systemd" hostame=? addr=? terminal=? res=failed and that is it. Rebooting with 'init=/sbin/upstart' immediately "fixes" the issue.
-- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #22) > AFAICT this is still utterly broken in rawhide. > systemd-11-1.fc15 > initscripts-9.21-5.fc15 Not anymore (although nobody bothered to mention that even in changelogs). Rebooting and powering off works for me with systemd-13-1.fc15 initscripts-9.22-2.fc15