[Nut-upsuser] Question on EATON UPS

Jim Klimov jimklimov+nut at gmail.com
Wed Mar 29 12:21:43 BST 2023


Which OS is that? With Linux+systemd, I'd expect systemd to start the
drivers (hence blocking the port) and keep logs in the systemd journal (if
your packaging includes nut-driver-enumerator, you may see them with
`journalctl -lu nut-driver at myups3`; for older systems just `journalctl -lu
nut-driver`), and on others init-scripts added by packaging should do the
same to start drivers when booted, and /var/log/syslog or /var/log/messages
or some such to hold the messages.

>From "2.8.0" in the log I assume it is packaged (and thankfully a recent
release), not a custom build of recent github sources.

As for the "infinite loop" - yes, that's what NUT drivers do as their day
job :)

Not returning the terminal is due to raised debug verbosity mode, it
historically defaults to staying foregrounded for easier Ctrl+C etc. NUT
2.8.0 should include -F/-B explicit options for some daemons (though not
upsdrvctl wrapper - that was added/fixed on master recently), so you can
e.g. run drivers backgrounded and verbose. It also includes "debug_min"
settings via ups.conf global or per-device sections, and via some other
daemon configs.

With raised verbosity, you would see lines about setting dstate entries
with readings at least. I think you interrupted the sent log too early, it
might have completed the initialization a few seconds later.

Thinking of it, there is also a data-dump mode, so the driver would
complete init, print the readings upsc-style, and exit, e.g.:

:; sudo /usr/lib/nut/usbhid-ups -a myups3 -DDD -d1

Hope this helps,
Jim

PS: Better not post screenshots as images to mailing lists, if that can be
avoided by posting texts/archives of those :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20230329/a7b05d81/attachment.htm>


More information about the Nut-upsuser mailing list