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
