networkupstools
NUT-server randomly loses connection to UPS (varying ~1 hour up to ~23 hours)
Hi, I recently bought a Powerwalker VI 2200 VHL which is USB-connected to a RPI5 (rpiOS).
I've got it setup correctly with the NUT-clients, but I've been experience varying connection loses (mails from NAS saying connection lost).
My journalctl is filled with: Mar 12 00:16:58 nut systemd[1]: Starting [email protected] - Network UPS Tools - device driver for NUT device 'ups'... Mar 12 00:17:24 nut systemd[1]: Stopped [email protected] - Network UPS Tools - device driver for NUT device 'ups'. (etc.)
I've tried changing maxage, pollfreq and also added [upswired] and [observer] with "upsmon primary", but I can't seem to get the connection to stick.
I don't know exactly what information is needed, and I'm not sure how to present it, but please let me know if any (and what) information is needed :-)
Hello, looking at the service instance use (per naming nut-driver@ups) I suppose you have at least NUT v2.8.0 or newer, with nut-driver-enumerator... Depending on NUT version and build options, there may be better or worse interaction with systemd as such (e.g. NUT drivers backgrounding can be seen as managed process dying, unless the service unit definition expects forking).
On one hand, which version is it - there were variations in systemd integration over subsequent development.
On another, do you have any competing attempts to start a driver (e.g. from command-line or crontab via upsdrvctl or direct calls to driver programs)? As detailed in https://github.com/networkupstools/nut/wiki/nut%E2%80%90driver%E2%80%90enumerator-(NDE) different start-ups of the driver can kill each other off, assuming a stuck older instance.
Here it looks suspicious that your service unit was stopped by systemd within half a minute from start. Try https://github.com/networkupstools/nut/wiki/Changing-NUT-daemon-debug-verbosity to see if it found the device at all, and had the rights to use it (maybe some other process, container, VM, hypervisor pass-through etc. intervened).
Also, generally speaking, take a look at related issues (I tagged yours with some labels that seem relevant).
There were quite a few reports in recent years about Raspberry (which may indicate an issue of the platform or just its popularity), with hearsay gauge that RPi 3 USB was problematic, RPi 4 less so, but RPi5 again often involved.
Maybe there are some kernel settings about power-saving (your USB chip going to sleep) or other hardware causing issues (EMI noise from luminescent lights and refrigerator motors, generally bad cabling, some USB flash stick causing bus-wide resets, etc.) and/or insufficient power source used for the RPi (wattage matters).
As a late-coming thought, disconnection/reconnection noise may be unfortunate and annoying, but resilience of the set-up and presumably no long-term loss of NUT coverage for your UPS even if the driver dies and gets restarted by systemd is in fact encouraging :) Way better than it was in init-script days where stuck or dead driver stayed that way until somebody noticed and kicked it up :)
Hi again @jimklimov,
I tried different configurations for removing power-saving mode for USB on my RPI5 but without any luck:
sudo nano /etc/rc.local
setterm -blank 0 -powerdown 0 -powersave off at line 0
It started off great with it staying connected for +24 hours, and then suddenly it stopped again. I've tried the same configuration with both Ubuntu, RaspOS and Debian for RPI5, but without any luck aswell. I also experienced a few instances where, if I plugged in more than one USB in the RPI, it would disconnect like crazy. At least a couple of times every minute, and this was non-stop. I can not rule out that the RPI is not functioning properly, and with the very limited knowledge I have, it might just be a fluke. However...
3 days ago I moved the install to a Debian 12.5.0 VM on my proxmox machine and got the USB-port passthrough'ed to the VM - and not a single disconnect as of yet, so I'm very happy :-)
I appreciate your fast help, and also the detailed answers you gave - they helped alot in troubleshooting. Even though it didn't end up working on the RPI, I appreciate the help you provided. Have a good weekend :-)