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 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 borked. > > 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. 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 -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
