[Nut-upsuser] NUT and Eaton UPS produce a lot of error messages

Fri Jan 19 16:24:23 GMT 2024

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>