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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20251004/402b04fb/attachment.sig>
Sam Varshavchik <mrsam at courier-mta.com> writes:> 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.It's really odd to lose power for 40 seconds in my experience. I wonder roughly where you are (looks like NA due to 120V, state?) and if you understand the mechanism for how it came back so fast. I would look in the logs and see if you can find that nut logged something about "low battery" or "forced shutdown". It is possible your batteries are tired, and it's possible that things are not configured right. You left out what the load on the UPS is. And battery type. I'm guessing 2 x 12V 7Ah size, perhaps labeled by marketing types as 9Ah. You left out the manufacture data / when you bought this. If it's 4 or 5 years old, sick batteries would not be surprising. If it's 1-2, they would be. But I don't have experience with CPS and if they treat the batteries better they may go longer.> 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.There are a bunch of things in that output that don't really make sense to me. I think you need to understand all the settings and then pull the UPS from the computer, put a light bulb or two on it, and do a test. But if you figure out that settings were odd and fix them, you are probably ok.> 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?I use a script running upsc and reporting via mqtt logging in home assistant, and thus have data for outages. But 40s is crazy.> battery.charge: 29 > battery.charge.low: 10 > battery.charge.warning: 2010 for low seems a bit low but not crazy. 29 is super low for having experience a 40s outage. I would see where it is after 48h.> battery.mfr.date: CPS > battery.runtime: 2939 > battery.runtime.low: 3002939s is a very good runtime, and 300s is a reasoable "when runtime is below this value, start shutdown".> 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: 0This seems off; the OS should be able to stop the inverter.> driver.name: usbhid-ups > driver.parameter.pollfreq: 30 > driver.parameter.pollinterval: 10 > driver.parameter.port: auto > driver.parameter.synchronous: autoI'm unclear on these. Did you get a log entry when power failed?> driver.state: quiet > driver.version: 2.8.1That's old. Update to the latest release. I know you're using Ubuntu and they are behind. Update anyway.> 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: enabledThat all seems ok.> ups.delay.shutdown: 20 > ups.delay.start: 30These are suspicious. Look up what they mean, and if ups.delay.shutdown is "after the killpower is sent, wait 20s before disabling the inverter" or if it means "start shutdown after 20s without power". I bet it's the first, but there are docs and there is source code.> ups.load: 6I'm guessing this is 6% of 1500 VA, or 90 VA. So you should with good batteries **and correct config** get much more than 40s, more like 30 minutes.> 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: -60These are interesting too, and strange. Figure these out too.> ups.vendorid: 0764The other suggestion is write a script that does (this is pseudocode not testedd!!0 while true; do output=`choose an output file name from some counter` upsc foo > $output sleep 1 done and then leave that running while you turn off the breaker or power strip for 15 seconds. Then analyze/think and report back. Do not unplug; that disconnects ground. The other thing you could do is disasemble, extract batteries, charge each of them up and do a controlled load test at C/20h to 10.5V logging everything, but I suspect you aren't set up for that.
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 aroundwith 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>