On Fri, 2006 Jul 28 14:46:47 -0300, Henrique de Moraes Holschuh wrote: > > 1. The UPS may take more than 15 minutes to shutdown the load. You cannot > assume things like this, and you will cause data loss if you get it wrong: > the power-off could come with the system fully online.
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. > 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.) > 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. > 4. It is very probable that in any non-home scenarios, an UPS will protect > more than one equipment. In those scenarios, the UPS is configured to NOT > accept "immediate shutdown the load" command from any of the equipments, > just from the main controller host. Nut is geared to work fine and > specifically support such configurations. This has to be taken into > account. 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. > 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. --Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
