Stefan Schumacher
2024-Jan-19 16:02 UTC
[Nut-upsuser] NUT and Eaton UPS produce a lot of error messages
Jan 19 05:50:13 mars nut-monitor[849]: Signal 15: exiting Jan 19 05:50:13 mars nut-monitor[849]: Network UPS Tools upsmon 2.8.0 Jan 19 05:50:13 mars systemd[1]: Stopping nut-monitor.service - Network UPS Tools - power device monitor and shutdown controller... Jan 19 05:50:13 mars systemd[1]: nut-monitor.service: Deactivated successfully. Jan 19 05:50:13 mars systemd[1]: Stopped nut-monitor.service - Network UPS Tools - power device monitor and shutdown controller. 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. Jan 19 05:50:44 mars usbhid-ups[845]: WARNING: send_to_all: write 31 bytes to socket 11 failed (ret=-1), disconnecting: Broken pipe Am Fr., 19. Jan. 2024 um 16:33 Uhr schrieb Matus UHLAR - fantomas <uhlar at fantomas.sk>:> > On 19.01.24 16:20, Stefan Schumacher via Nut-upsuser wrote: > >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? > > perhaps Eaton Ellipse would be fine. > > The message above does not look like a problem of the UPS. > Was there anything other in the logs, before the message above? > > >Am Fr., 19. Jan. 2024 um 10:54 Uhr schrieb Jim Klimov via Nut-upsuser > ><nut-upsuser at alioth-lists.debian.net>: > >> > >> With recent NUT releases, driver disconnections should be contained in its own `nut-driver at 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 <uhlar at fantomas.sk> 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 < > >>> >nut-upsuser at alioth-lists.debian.net> 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 at 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 at 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 at localhost] failed - Write error: Broken pipe > >>> >> Jan 19 05:17:04 servername nut-monitor[849]: Communications with UPS > >>> >> Eaton at 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 at localhost] failed - got [ERR ACCESS-DENIED] > >>> >> Jan 19 05:17:14 servername nut-monitor[849]: Communications with UPS > >>> >> Eaton at localhost established > >>> >> Jan 19 05:17:14 servername nut-monitor[1312]: Network UPS Tools upsmon > >>> >> 2.8.0 > >>> > >>> > >>> -- > >>> Matus UHLAR - fantomas, uhlar at fantomas.sk ; 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 > >>> Nut-upsuser at alioth-lists.debian.net > >>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser > >> > >> _______________________________________________ > >> Nut-upsuser mailing list > >> Nut-upsuser at alioth-lists.debian.net > >> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser > > > >_______________________________________________ > >Nut-upsuser mailing list > >Nut-upsuser at alioth-lists.debian.net > >https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser > > -- > Matus UHLAR - fantomas, uhlar at fantomas.sk ; 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. > Micro$oft random number generator: 0, 0, 0, 4.33e+67, 0, 0, 0... > > _______________________________________________ > Nut-upsuser mailing list > Nut-upsuser at alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
Jim Klimov
2024-Jan-19 16:24 UTC
[Nut-upsuser] NUT and Eaton UPS produce a lot of error messages
Can you please check what was previous to the signal 15 (graceful termination)? With `journalctl -lu nut-server` or with longer `systemctl status -n 50 nut-server` if that works for yours? Also, check NUT Wiki or other docs about using `debug_min` setting woth 2.8.0+ to bump it and have more context about why differebt daemons decide to do whatever they do (e.g. restart). For all I know from the few lines here, the restart of services could be auto-updates rebooting the server, unrelated to NUT or UPS. Or not. Just got too little to say anything definite. Good luck, Jim On Fri, Jan 19, 2024, 17:02 Stefan Schumacher via Nut-upsuser < nut-upsuser at alioth-lists.debian.net> wrote:> Jan 19 05:50:13 mars nut-monitor[849]: Signal 15: exiting > Jan 19 05:50:13 mars nut-monitor[849]: Network UPS Tools upsmon 2.8.0 > Jan 19 05:50:13 mars systemd[1]: Stopping nut-monitor.service - > Network UPS Tools - power device monitor and shutdown controller... > Jan 19 05:50:13 mars systemd[1]: nut-monitor.service: Deactivated > successfully. > Jan 19 05:50:13 mars systemd[1]: Stopped nut-monitor.service - Network > UPS Tools - power device monitor and shutdown controller. > 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. > Jan 19 05:50:44 mars usbhid-ups[845]: WARNING: send_to_all: write 31 > bytes to socket 11 failed (ret=-1), disconnecting: Broken pipe > > Am Fr., 19. Jan. 2024 um 16:33 Uhr schrieb Matus UHLAR - fantomas > <uhlar at fantomas.sk>: > > > > On 19.01.24 16:20, Stefan Schumacher via Nut-upsuser wrote: > > >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? > > > > perhaps Eaton Ellipse would be fine. > > > > The message above does not look like a problem of the UPS. > > Was there anything other in the logs, before the message above? > > > > >Am Fr., 19. Jan. 2024 um 10:54 Uhr schrieb Jim Klimov via Nut-upsuser > > ><nut-upsuser at alioth-lists.debian.net>: > > >> > > >> With recent NUT releases, driver disconnections should be contained > in its own `nut-driver at 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 < > uhlar at fantomas.sk> 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 < > > >>> >nut-upsuser at alioth-lists.debian.net> 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 at 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 at 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 at localhost] failed - Write error: Broken pipe > > >>> >> Jan 19 05:17:04 servername nut-monitor[849]: Communications with > UPS > > >>> >> Eaton at 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 at localhost] failed - got [ERR ACCESS-DENIED] > > >>> >> Jan 19 05:17:14 servername nut-monitor[849]: Communications with > UPS > > >>> >> Eaton at localhost established > > >>> >> Jan 19 05:17:14 servername nut-monitor[1312]: Network UPS Tools > upsmon > > >>> >> 2.8.0 > > >>> > > >>> > > >>> -- > > >>> Matus UHLAR - fantomas, uhlar at fantomas.sk ; 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 > > >>> Nut-upsuser at alioth-lists.debian.net > > >>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser > > >> > > >> _______________________________________________ > > >> Nut-upsuser mailing list > > >> Nut-upsuser at alioth-lists.debian.net > > >> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser > > > > > >_______________________________________________ > > >Nut-upsuser mailing list > > >Nut-upsuser at alioth-lists.debian.net > > >https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser > > > > -- > > Matus UHLAR - fantomas, uhlar at fantomas.sk ; 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. > > Micro$oft random number generator: 0, 0, 0, 4.33e+67, 0, 0, 0... > > > > _______________________________________________ > > Nut-upsuser mailing list > > Nut-upsuser at alioth-lists.debian.net > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser > > _______________________________________________ > 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/20240119/181903db/attachment-0001.htm>
Matus UHLAR - fantomas
2024-Jan-19 16:59 UTC
[Nut-upsuser] NUT and Eaton UPS produce a lot of error messages
On 19.01.24 17:02, Stefan Schumacher via Nut-upsuser wrote:>Jan 19 05:50:13 mars nut-monitor[849]: Signal 15: exiting>Jan 19 05:50:17 mars nut-server[1303]: Signal 15: exitingthis looks like someone repeatedly killed nut server. This not a problem of UPS. -- Matus UHLAR - fantomas, uhlar at fantomas.sk ; 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. Atheism is a non-prophet organization.