[Nut-upsuser] Ex post facto logging

[Jim Klimov]

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/20251005/f5de2216/attachment.htm>