[Nut-upsuser] Ex post facto logging

[Jim Klimov]

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 <jimklimov+nut at gmail.com> 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
> `nut-driver at nutdev1.service`, `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 <mrsam at courier-mta.com>
> 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
>> Nut-upsuser at alioth-lists.debian.net
>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20251012/3dfc369e/attachment.htm>