Nut upsuser - Jan 2024 - NUT and Eaton UPS produce a lot of error messages

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
<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

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...

Stefan Schumacher via Nut-upsuser writes:
> 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?
I've had good experience with Cyberpower units, as long as they're
included
NUT's hardware list.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL:
<http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20240119/b113280f/attachment.sig>