On Fri, 28 Jul 2006, Daniel Richard G. wrote: > The time period should be configurable; I just suggested 15 minutes as a > default. You could set a higher value, but the tradeoff is that if the > power returns, the system is unavailable for that time period.
There is no tradeoff without the hack, and the hack is only needed in hardware unsuitable for UPS management. Thus, it must be optional. It is dangerous to data and the hardware, so it should not be the default. It is fairly simple, really, unless I missed something major (which is always possible). > > 2. Not powering off the box by itself (read: allowing halt and the kernel to > > do its job and cut power cleanly) means it will be subject to high > > transients when the UPS shuts down the load. This will, in turn, make it > > worse for the other loads that have not been properly shut down. It would > > be a disaster in a server farm. > > Please elaborate on how server equipment is subjected to a transient when a > UPS cuts power to it. (If anything, the situation is much worse when it is > powered back on.) You have transient responses to power cuts. Watch in an osciloscope, computer hardware is not a resistive load. The situation is bad when everything powers up at the same time too, yes. That's why it isn't all powered up at once in server rooms, blade enclosures, etc. > > 3. Non-controlled shutdowns are *very* bad for all hardware, including > > desktop systems. For starters, all disks will be subject to emergency head > > unloads. The halt utility does a lot of work-around on kenrel bugs to make > > sure disks are parked, RAID arrays are in read-only mode or shutdown, etc > > for a damn good reason. > > All of which can be done (and already is, I believe). The only thing that > the system is doing while waiting for poweroff is "sleep 15m; reboot"---no > disks need to be spinning for that. If you did not call halt, plus told the kernel to shutdown the devices, no, it was *not* done. And the kernel is the *only* thing that really knows how to properly powerdown the devices. Currently, we cannot ask it to do so from userspace easily, and if we did, we could not access the disks anymore for example. > Isn't this already the case for non-networked UPSes? When the interface is > serial or USB, it can only be connected to (and controlled by) a single, > master host. The issue is how the initscript behaves if the NUT shutdown command doesn't kill everything to kingdon come in 5 seconds. In fact, a proper UPS is going to be programmed to actually *delay* the powerdown load command for enough time to allow the load to try to powerdown for real by itself. > > Thus, implementing the work around proposed in this bug report as a default > > behaviour is not acceptable. Please revert the change, or make it optional, > > and *not* enabled by default. I would go even further and actively > > discourage heavily the use of this option, as it can damage the hardware. > > I think you'll take issue with the NUT documentation, then, as it > specifically suggests this approach. I will. But maybe, perchance, the NUT docs don't suggest you do it unless you own hardware that cannot do it properly? I didn't read it yet. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
