One more data point, courtesy of https://github.com/networkupstools/nut/issues/1962#issuecomment-3394200977 discussion - if a driver instance started as `drivername -k` finds an already-running driver, it sends two protocol requests, one to SET driver.flag.allow_killpower 1 and another to actually INSTCMD driver.killpower, so for that use-case the setting in `ups.conf` is not required.
Per same discussion, I suppose there may be a regression in v2.8.3 and v2.8.4 about some drivers not detecting all the INSTCMD's they support when quickly initializing for killpower-and-exit operations. Gotta revise now if this is the case, and if some `shutdown.*` commands are impacted in particular anywhere (seems likely that `riello_usb` in that discussion is...) Hope this helps, Jim Klimov On Sun, Oct 5, 2025 at 3:00 PM Jim Klimov <[email protected]> wrote: > Cheers all, > > I feel a bit late to the party, so would respond to some points from > different mails: > > * Indeed, such an early shutdown is not too healthy. Debug-logging in > daemons would expose more about how/when/why it decided to go down, e.g. if > the UPS raised the "OB+LB" flags practically simultaneously (because > battery is old, or assumed weak based on some calibration info, etc.) and > the NUT driver forwarded it to the data server (upsd), and the monitoring > client (upsmon) decided to raise the FSD flag and scuttle the ship. Other > alternatives may involve upssched as upsmon's NOTIFYCMD and a timer setup > there to "go down if we are on battery longer than X", which is a custom > but not too uncommon way of setting up NUT. > See > https://github.com/networkupstools/nut/wiki/Changing-NUT-daemon-debug-verbosity > for > some ideas about bumping debug verbosity with modern NUT versions without > changing init/systemd scripts etc. > > * > > I would look in the logs and see if you can find that nut logged > something about "low battery" or "forced shutdown". > > Well, that's what I'm asking. Where do I find these logs. I poked > around with journalctl, and found just startup and shutdown messages. > > It depends :) For a wholesale picture of everything happening on your > system in more or less timely order, go as root to run `journalctl -xl`. > For individual NUT-related units, probably use `systemctl -a | egrep -i > 'nut|ups'` to see what is relevant on your system, and `journalctl -lu > unitname` to check its logs specifically. You would probably be after > `[email protected]`, `nut-server` and `nut-monitor` units. > > * > write a script that does (this is pseudocode ...) > For logging of different data points (e.g. ups.status, battery.charge) > over time, consider https://networkupstools.org/docs/man/upslog.html - in > recent releases it also has a systemd service based on > https://github.com/networkupstools/nut/blob/master/scripts/systemd/nut-logger.service.in > that you can configure with UPSLOG_ARGS saved in a file. It should > `fflush()` after every write, so hopefully most of the info up to power > loss would be saved. > > * > > driver.flag.allow_killpower: 0 > > This seems off; the OS should be able to stop the inverter. > > Not quite, this flag is a failsafe to not allow a running driver daemon to > call INSTCMD's that kill power by default - normally during shutdowns, > services die and later a separate driver instance starts with `-k` option > just to tell the UPS to kill power. This flag allows one to flip the safety > switch and try to do this (via socket protocol) on a running system. Not > really tested much though, but opens ways to different administration > approaches than was possible in preceding years. > > * Re: Older NUT: custom-building a drop-in replacement for whatever is > installed should be more or less streamlined nowadays, see > https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests > > Hope this helps, > Jim Klimov > > > > On Sat, Oct 4, 2025 at 2:20 PM Sam Varshavchik <[email protected]> > wrote: > >> I lost power for about 40 seconds. From what I can see NUT quickly shut >> down >> the system and boot it back up when power was restored. That also >> worked. >> Everything worked as designed, except I would expect such a brief >> shutdown >> to be survivable. >> >> The only question mark in my mind is that the battery should've been >> enough >> to last those measly 40 seconds. Output of upsc is below. This is about >> an >> hour after the power was restored, and I see that battery.charge is only >> 29, >> and it is slowly increasing. >> >> So, I think is that my batteries are due for a replacement. I would've >> wanted to see what was logged during the outage, but I can't find >> anything >> in journalctl for nut-monitor or nut-server. This is Ubuntu 24. Should >> there >> be something logged, somewhere? >> >> battery.charge: 29 >> battery.charge.low: 10 >> battery.charge.warning: 20 >> battery.mfr.date: CPS >> battery.runtime: 2939 >> battery.runtime.low: 300 >> battery.type: PbAcid >> battery.voltage: 27.3 >> battery.voltage.nominal: 24 >> device.mfr: CPS >> device.model: CP1500AVRLCDa >> device.serial: BHQLW7002402 >> device.type: ups >> driver.debug: 0 >> driver.flag.allow_killpower: 0 >> driver.name: usbhid-ups >> driver.parameter.pollfreq: 30 >> driver.parameter.pollinterval: 10 >> driver.parameter.port: auto >> driver.parameter.synchronous: auto >> driver.state: quiet >> driver.version: 2.8.1 >> driver.version.data: CyberPower HID 0.8 >> driver.version.internal: 0.52 >> driver.version.usb: libusb-1.0.27 (API: 0x100010a) >> input.voltage: 120.0 >> input.voltage.nominal: 120 >> output.voltage: 120.0 >> ups.beeper.status: enabled >> ups.delay.shutdown: 20 >> ups.delay.start: 30 >> ups.load: 6 >> ups.mfr: CPS >> ups.model: CP1500AVRLCDa >> ups.productid: 0501 >> ups.realpower.nominal: 900 >> ups.serial: BHQLW7002402 >> ups.status: OL CHRG >> ups.test.result: No test initiated >> ups.timer.shutdown: -60 >> ups.timer.start: -60 >> ups.vendorid: 0764 >> >> _______________________________________________ >> Nut-upsuser mailing list >> [email protected] >> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser >> >
_______________________________________________ Nut-upsuser mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
