mzerqung at 0pointer.de
Wed May 18 21:04:33 UTC 2011
On Mon, 16.05.11 14:30, Simo Sorce (ssorce at redhat.com) wrote:
> On Mon, 2011-05-16 at 18:59 +0200, Lennart Poettering wrote:
> > On Mon, 16.05.11 14:32, Michal Hlavinka (mhlavink at redhat.com) wrote:
> > > when ups recieves command for shutdown, it does not shutdown power
> > > immediately, but after 30 seconds. Given that this command should be executed
> > > after umount, synced disks,... when everything is ready for power off...
> > > 30 seconds proved to be enough time for this.
> > This is not the case and never has been the case. The root disks
> > traditionally could not be unmounted and hence MD/DM/MP and so on could
> > not be disassembled before going down.
> > Delaying shutdown by 30s is hack, not a fix for a race.
> What race are we talking about exactly ?
Host requests power down from UPS in 30s. Host then continues shut
down. If the host now ends up taking more time then expected for
shutting down it might still be busy at the time of the power going
away. It's a race between "UPS powering off" and "system finishing
shutdown". It's a bet that your system is faster than 30s when
unmounting the remaining file systems, syncing the MD/DM metadata to
disk, syncing ATA and so on (i.e. all the stuff the kernel does when you
invoke the reboot() syscall).
> You do realize that the *UPS* itself is programmed to shut down after
> 30 seconds ? there is no sleep(30) here ...
Yes, but that is irrelevant for the race.
> > > > UPS code like that needs to sit in the kernel itself to properly
> > > > work. Adding userspace kludges which invokes this from userspace is a
> > > > recipe for desaster.
> > >
> > > If *you* wan't to write kernel drivers for tons of UPS models using
> > > serial/usb/network/... connections with tons of protocols (with incomplete
> > > documentation)... it's your freedom to do so ;)
> > Well, what can I say. I don't maintain UPS stuff, I don't use UPS
> > stuff.
> Oh this was *very* clear, no doubt you have never seen one. And given
> you haven't can you stop prescribing how things should work and instead
> discuss how we can make things work as things stand now ?
Well, I am not stupid. I can see a race when there is one. Are you claiming
the race above doesn't exist?
> You are the one pushing systemd, it is your duty to address the cases
> when it has to step out of the perfect world and actually meet the
> reality of how things actually work out there.
Right, and so I did. And I also pointed out that the current scheme is
> > I am just pointing you to the fact that the current approach here
> > is racy, but sorry, I won't fix this for you.
> Given a lot of UPSes have "drivers" written in proprietary Java programs
> and communicate to the device via serial/usbserial, there isn't much you
> can do on the kernel driver front.
I am pretty sure we don't want to run Java programs at late boot, as
root. This would be really bad.
In F16 we hope to make it possible to unmount the root fs at
shutdown. It will be the first time we can do something like this. To
implement this we'll have to copy the shutdown code into a tmpfs and
then replace the root dir with the tmpfs. We definitely don't want to
copy the JRE into the tmpfs before going down.
Lennart Poettering - Red Hat, Inc.
More information about the devel