Hello and thanks for all the replies. This morning at 9:50 the server stopped working unexpectedly - I was still sleeping until 10:00, so no user intervention took place.
Jan 19 05:50:17 mars nut-server[1303]: mainloop: Interrupted system call Jan 19 05:50:17 mars nut-server[1303]: Signal 15: exiting Jan 19 05:50:17 mars nut-server[1303]: Network UPS Tools upsd 2.8.0 Jan 19 05:50:17 mars systemd[1]: Stopping nut-server.service - Network UPS Tools - power devices information server... Jan 19 05:50:17 mars upsd[1303]: mainloop: Interrupted system call Jan 19 05:50:17 mars upsd[1303]: Signal 15: exiting Jan 19 05:50:17 mars systemd[1]: nut-server.service: Deactivated successfully. Jan 19 05:50:17 mars systemd[1]: Stopped nut-server.service - Network UPS Tools - power devices information server. I am considering returning the device to the online shop I bought. As it is, it's nothing but trouble. Can you recommend a small UPS (1 Server) that is guaranteed to work flawlessly with NUT? Yours Stefan Am Fr., 19. Jan. 2024 um 10:54 Uhr schrieb Jim Klimov via Nut-upsuser <[email protected]>: > > With recent NUT releases, driver disconnections should be contained in its > own `nut-driver@eaton` instance (the `@upsname` part is derived from the > `ups.conf` section name). One of the drivers failing and restarting is not a > proper cause for the data server to recycle. > > Also, nowadays some (maybe not all) USB-capable drivers should try to > reconnect without restarting. Note however, that in some NUT iterations it is > possible that this feature misfires if the devices get re-enumerated and the > driver tries to reuse results of original libusb discovery (e.g. some kernels > add +1 to "device" number upon each reconnection, such as due to USB chip/hub > reset, EMI causing protocol reset, or a device going to sleep and yanked back > to work). > > In fact, recent work on master branch got `nut-scanner` to not suggest the > `device` option by default to avoid such situations. > > Jim > > > On Fri, Jan 19, 2024 at 9:36 AM Matus UHLAR - fantomas <[email protected]> > wrote: >> >> On 19.01.24 09:00, Jim Klimov via Nut-upsuser wrote: >> >Well, from your logs it seems that at 05:17:03 your nut-server (upsd) >> >restarted, so an upsmon reconnection attempt at 05:17:09 had an issue with >> >that (config not all applied? strange a bit) but since 05:17:14 it is okay. >> > >> >Maybe a few too many banners shown from upsmon, while its same uptime seems >> >to continue. Maybe someone should check on that, seems like a good and easy >> >newcomer issue to learn the code, so PRs are welcome :D >> > >> >Messages about lack of "*.pid" files are okay, they should look less scary >> >in newer releases of NUT. They confirm that there is no previous daemon >> >with the same basic configuration currently running, so that your new >> >instance might conflict with it or send it some signals intentionally - so >> >it is just a new start in a clean environment with no competitors. >> > >> >It is a bit unfortunate that both syslog (upsd) and stderr (nut-server) >> >messages land into the same systemd journal. It may be possible to add >> >auto-detection of systemd and not-emit one of those streams then, or add an >> >option for that to be quieter and better readable (some people can have a >> >separate syslog setup anyway, maybe on a remote "sink" system, so just >> >cutting one off always is not right). >> > >> >So one question that remains is the missing lines from previous lifetime in >> >the short excerpt of upsd: why did it restart at that time? :) >> >> I also have Eaton UPS, just different model. It sometimes disconnects and >> nut has to connect again. I guess this is what happened. >> >> I assume the disonnect message is not visible in "Systemctl status" message >> because it does not belong to the current process but previous one. >> Looking for syslog (/var/log/messages) or journal messages (journalctl) could >> show that. I guess nothing bad happened there. >> >> >On Fri, Jan 19, 2024 at 6:13 AM Stefan Schumacher via Nut-upsuser < >> >[email protected]> wrote: >> >> I recently bought a small UPS by Eaton (Ellipse ECO 800) in order to >> >> prevent my >> >> btrfs-fileserver (running Debian 12 Bookworm 12.4 from shutting down >> >> abruptly while writing >> >> something important during a power loss. I am using the version >> >> 2.8.0.7 provided by Debian. >> >> I have found very gooddocumentation 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. >> >> >> >> I will now describe the steps I took and the configuration options I >> >> set and then post the errors of nut-monitor and nut server. I hope >> >> someone can help fix the underlying problem behind these error >> >> messages. >> >> >> >> lsusb shows the UPS: >> >> Bus 001 Device 003: ID 0463:ffff MGE UPS Systems UPS >> >> >> >> So I made this changes to ups.conf >> >> [Eaton] >> >> driver = usbhid-ups >> >> port = auto >> >> vendorid = 0463 >> >> pollfreq = 30 >> >> >> >> In nut.conf I set mode=standalone. >> >> >> >> And finally I added these lines to upsd.users: >> >> [upsmon] >> >> password = XXXX >> >> actions = SET >> >> instcmds = ALL >> >> >> >> I did a live test, plugged the cord and waited until the server shut >> >> down at 20%. Worked fine. >> >> Upsc also works - I can query my UPS for specific parameters or show them >> >> all. >> >> >> >> 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 ? >> >> >> >> ● 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 >> >> >> >> ● 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 >> >> 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 >> >> >> -- >> Matus UHLAR - fantomas, [email protected] ; http://www.fantomas.sk/ >> Warning: I wish NOT to receive e-mail advertising to this address. >> Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. >> Spam = (S)tupid (P)eople's (A)dvertising (M)ethod >> >> _______________________________________________ >> 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 _______________________________________________ Nut-upsuser mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
