Thanks Charles for the clarification. If NUT cannot control it then removing it would, IMO add value.
On Sun, 10 Mar 2024 at 00:14, Charles Lepple < [email protected]> wrote: > On Mar 9, 2024, at 5:16 PM, [email protected] wrote: > > > > The posting at > https://github.com/networkupstools/nut/issues/432#issuecomment-405371395 > references ups.delay.start and suggests setting it to -1. > > > > upsrw -l pve1@localhost listed this as modifiable but any attempt at > modifying the value failed. I used the override.ups.delay.start = -1 in > nut.conf and this is now being reported. > > My original suggestion (which implies the use of override.*) is mainly for > setting values that the UPS driver uses to decide when to shut down (if it > is told to ignore the UPS LB flag, and must calculate the LB condition in > the driver). > > ups.delay.start is a value that is only interpreted by the UPS hardware > (the driver just passes it through to upsd/upsc when override.* is not in > play). So IMHO it doesn't make sense to override it, unless you have > something else that needs to read it. In most cases, the startup delay > happens when NUT is not running yet (assuming the machine with upsd/driver > is powered by that UPS). > > If the UPS won't let you change a delay variable, then I don't think > override is going to help here. > > > Two observations are that once a variable setting is overridden, upsrw > -w will not show these values. Is it by design? > > > Others will have to speak to the design rationale of override.* and > default.*, but I guess I tend to think of override.* as hard-coding a value > in the driver (and therefore something that I wouldn't attempt to change > with upsrw, but with the conf file instead). I guess that probably means > the variable should be removed from the list of read/write variables.
_______________________________________________ Nut-upsuser mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
