On Wed, 2011-05-18 at 23:04 +0200, Lennart Poettering wrote: > On Mon, 16.05.11 14:30, Simo Sorce (ssorce@xxxxxxxxxx) wrote: > > > > > On Mon, 2011-05-16 at 18:59 +0200, Lennart Poettering wrote: > > > On Mon, 16.05.11 14:32, Michal Hlavinka (mhlavink@xxxxxxxxxx) 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 it is a race to get it done before the UPS runs out of battery anyway ? It's not perfect, but sysadmins are capable of assessing how much time each of their server needs to shut down and make the UPS wait long enough (battery permitting of course). > > 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. Call it a race, call it a run, doesn't matter it is how things works in this world right now. I guess you could try to convince UPS vendors to use better ways, but that's not how physical devices available to the public work right now. > > > > > 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 looking at the finger while people are pointing to the moon right now. > > 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 > borked. I am sorry that reality bothers you so much, but it is the hard old real world ... > > > 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. > > Hmm? > > I am pretty sure we don't want to run Java programs at late boot, as > root. This would be really bad. You know, it's not like there is a choice for many models ... > 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. It is not necessary, the hook can be called before you do that last operation, the driver will command the UPS to wait long enough for that operation to finish in time in 99% of the cases. For the remaining 1% of the cases, admins will have to re-tune the delay once power comes up and they find it wasn't enough time after all. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
