Stefan Schumacher wrote: > Hello > > I recently bought a small UPS by Eaton in order to prevent my > btrfs-fileserver (running Debian 12 Bookworm, which is also the source > of my nut-installation) from shutting down abruptly while writing > something important during a power loss. I have found very good > documentation on how to set up the UPS and the services on the server > connected to it. Unfortunately it's in German > (https://techbotch.org/blog/ups-setup/index.html) which is not a > problem for me but possibly for others trying to understand my set-up.
> The problem is the dozens of errors the systemctl status messages > show. I bought the UPS to increase reliability and now I don't know if > the service is working in case of an emergency. How can I fix this ? > Should I try to contact the Package Maintainer? Are there alternatives > I could use or is nut the gold standard? > > ● nut-server.service - Network UPS Tools - power devices information server > Loaded: loaded (/lib/systemd/system/nut-server.service; enabled; > preset: enabled) > Active: active (running) since Fri 2024-01-19 05:17:03 CET; 5s ago > Main PID: 1303 (upsd) > Tasks: 1 (limit: 38253) > Memory: 640.0K > CPU: 3ms > CGroup: /system.slice/nut-server.service > └─1303 /lib/nut/upsd -F > Jan 19 05:17:03 servername nut-server[1303]: fopen /run/nut/upsd.pid: > No such file or directory > Jan 19 05:17:03 servername nut-server[1303]: Could not find PID file > '/run/nut/upsd.pid' to see if previous upsd instance is already > running! > Jan 19 05:17:03 servername nut-server[1303]: listening on 127.0.0.1 port 3493 > Jan 19 05:17:03 servername nut-server[1303]: listening on ::1 port 3493 > Jan 19 05:17:03 servername upsd[1303]: listening on 127.0.0.1 port 3493 > Jan 19 05:17:03 servername upsd[1303]: listening on ::1 port 3493 > Jan 19 05:17:03 servername nut-server[1303]: Connected to UPS [Eaton]: > usbhid-ups-Eaton > Jan 19 05:17:03 servername upsd[1303]: Connected to UPS [Eaton]: > usbhid-ups-Eaton > Jan 19 05:17:03 servername upsd[1303]: Running as foreground process, > not saving a PID file > Jan 19 05:17:03 servername nut-server[1303]: Running as foreground > process, not saving a PID file So far, we aren't seeing any errors at all. This is just startup logging. > ● nut-monitor.service - Network UPS Tools - power device monitor and > shutdown controller > Loaded: loaded (/lib/systemd/system/nut-monitor.service; enabled; > preset: enabled) > Active: active (running) since Fri 2024-01-19 03:37:28 CET; 1h 41min ago > Main PID: 847 (upsmon) > Tasks: 2 (limit: 38253) > Memory: 3.4M > CPU: 338ms > CGroup: /system.slice/nut-monitor.service > ├─847 /lib/nut/upsmon -F > └─849 /lib/nut/upsmon -F > Jan 19 03:43:08 servername nut-monitor[849]: UPS Eaton@localhost on battery > Jan 19 03:43:09 servername nut-monitor[916]: Network UPS Tools upsmon 2.8.0 > Jan 19 03:43:33 servername nut-monitor[849]: UPS Eaton@localhost on line power > Jan 19 03:43:34 servername nut-monitor[920]: Network UPS Tools upsmon 2.8.0 The UPS decided to activate, then decided to go back to the line. This might be a power fluctuation -- quite possibly an undervoltage so brief that nothing else in the house noticed. > Jan 19 05:17:04 servername nut-monitor[849]: Poll UPS > [Eaton@localhost] failed - Write error: Broken pipe > Jan 19 05:17:04 servername nut-monitor[849]: Communications with UPS > Eaton@localhost lost > Jan 19 05:17:04 servername nut-monitor[1305]: Network UPS Tools upsmon 2.8.0 > Jan 19 05:17:09 servername nut-monitor[849]: Login on UPS > [Eaton@localhost] failed - got [ERR ACCESS-DENIED] > Jan 19 05:17:14 servername nut-monitor[849]: Communications with UPS > Eaton@localhost established > Jan 19 05:17:14 servername nut-monitor[1312]: Network UPS Tools upsmon 2.8.0 That, however, is lost-and-regained communication with the UPS. It might be a bad USB cable, a reset of the UPS's controller, a USB controller issue... Does it happen repeatedly? Does it ever not re-connect? -dsr-
