Bug 605519 - System does not poweroff
System does not poweroff
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: initscripts (Show other bugs)
rawhide
All Linux
low Severity high
: ---
: ---
Assigned To: Bill Nottingham
Fedora Extras Quality Assurance
: Reopened
: 615796 619927 622493 623247 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-18 03:34 EDT by Fabian Deutsch
Modified: 2014-03-16 23:23 EDT (History)
22 users (show)

See Also:
Fixed In Version: initscripts-9.16-2.fc14
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-11-19 16:45:27 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Fabian Deutsch 2010-06-18 03:34:44 EDT
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
Comment 1 pankaj pandey 2010-07-09 06:44:46 EDT
The message is something like:
"Not stopping monitoring. This is a dangerous operation. Use force-stop."
Comment 2 Fabian Deutsch 2010-07-09 07:06:38 EDT
Yes.

But the situation improved after some updated. Now it cycles through a couple of unmount cycles and shuts down.
Comment 3 pankaj pandey 2010-07-10 09:37:05 EDT
Doesn't work for me yet, even the latest systemd 2 version. It did not shut down, i waited for 10 minutes.
Comment 4 Lennart Poettering 2010-07-13 19:25:10 EDT
Could you please retry with v3?

The umount thing is known and needs to be fixed in the initscripts package, see bug 612789.
Comment 5 Michal Schmidt 2010-07-14 10:13:07 EDT
(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.
Comment 6 Orion Poplawski 2010-07-16 17:24:22 EDT
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.
Comment 7 Rahul Sundaram 2010-07-18 17:25:12 EDT
*** Bug 615796 has been marked as a duplicate of this bug. ***
Comment 8 Bug Zapper 2010-07-30 08:09:45 EDT
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
Comment 9 Adam Williamson 2010-07-30 15:44:32 EDT
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
Comment 10 Michal Jaegermann 2010-08-01 09:57:36 EDT
*** Bug 619927 has been marked as a duplicate of this bug. ***
Comment 11 Michal Schmidt 2010-08-02 08:56:08 EDT
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
Comment 12 Bill Nottingham 2010-08-02 12:45:05 EDT
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
Comment 13 Bill Nottingham 2010-08-02 12:54:33 EDT
And yes, the typo in the above commit is fixed upstream.
Comment 14 James Cassell 2010-08-03 08:03:32 EDT
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
Comment 15 Lennart Poettering 2010-08-06 07:33:29 EDT
OK, so I figure this may now be closed with Bill's fix?
Comment 16 Michal Schmidt 2010-08-06 07:41:31 EDT
Bill's patch is only in upstream. An update of initscripts is needed.
Comment 17 Adam Williamson 2010-08-08 00:08:09 EDT
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
Comment 18 Michal Schmidt 2010-08-09 10:30:41 EDT
*** Bug 622493 has been marked as a duplicate of this bug. ***
Comment 19 Fedora Update System 2010-08-09 13:05:28 EDT
initscripts-9.16-2.fc14 has been submitted as an update for Fedora 14.
http://admin.fedoraproject.org/updates/initscripts-9.16-2.fc14
Comment 20 Fedora Update System 2010-08-10 20:20:02 EDT
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.
Comment 21 Horst H. von Brand 2010-08-11 13:22:07 EDT
*** Bug 623247 has been marked as a duplicate of this bug. ***
Comment 22 Michal Jaegermann 2010-10-27 13:30:11 EDT
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.
Comment 23 Adam Williamson 2010-10-27 17:19:53 EDT

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 24 Michal Jaegermann 2010-11-19 16:45:27 EST
(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

Note You need to log in before you can comment on or make changes to this bug.