[Nut-upsdev] Important regression in usbhid-ups (r1113)

[Arjen de Korte]

Peter Selinger wrote:

> I am not saying that you are wrong; only that this particular behavior
> should be reconsidered. You are right that when you changed the
> default to 20 seconds, you only followed what was written on the
> usbhid-ups man page all along. However, browsing the man pages, I
> found that the default offdelay value is:
> 
> 0 in the megatec driver
> undefined in the megatec_usb driver
> 20 seconds in the mge-shut driver
> 120 seconds in the mge-utalk driver
> 64 seconds in the tripplite driver
> undefined in the tripplite_usb driver
> 20 seconds in the usbhid-ups driver
> and undefined in all other drivers, according to their man pages.
> 
> This violates the common-sense rule that the default behavior should
> not be something arbitrary and unpredictable. In my opinion, the only
> reasonable default value that is not arbitrary is 0. 
> 
> As the discussions on some Debian mailing list: I believe each
> packager (including Debian) is free to set their own defaults, which
> are designed to work best with that packager's shutdown scripts
> etc. However, the defaults in the source distribution should work well
> with a standard from-source installation as described in the file
> INSTALL, and should be as intuitive as possible. 
> 
> Intuitively, when I type "upsdrvctl shutdown", I expect the power to
> shut down. If nothing happens, I will think there is a problem and
> start doing something else. Then, in the middle of something else, the
> power will suddenly go off, and I will not be sure why. Moreover,
> neither the description of "shutdown" in the upsdrvctl(8) man page,
> nor the description of "-k" in the nutupsdrv(8) man page mentions a
> delay, much less an arbitrary driver-specific default delay.
> 
> As you point out, there will be some users that need to shut down
> their harddrives by some other method before cutting their power
> supply. But such users will either be following alternate instructions
> (which should then also direct them to set the offdelay value - this
> is even necessary currently because the default is a driver specific
> value). Or else such users will know what they are doing and why.
> 
> For all of these reasons, I propose to make the new default offdelay
> "0" system-wide through all drivers. 

I agree with most (if not all) of your arguments here. We're still far
off from a uniform behavior for all subdrivers (and not only in this
aspect). However, I'm not sure how (and if) we could change this,
without risking breaking existing installations. Especially for the
shutdown behavior, where any changes will probably surface at the worst
possible moment.

People will only find out that we lowered the defaults until it is too
late. It is not only the master systems that I'm worried about (if this
is called at the last stage in the halt script, there probably isn't
that much difference), but also for the slaves. From the time the the
FSD flag is set by the master, shutdown for the master and slaves is no
longer synchronized. So even if the master doesn't really need this
additional delay in shutting down, the slaves may not have finished yet.

Best regards, Arjen