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
