Nut upsuser - Mar 2023 - Question on EATON UPS

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>

Hi Jim,

I?m using on Kali Linux.

I?m not using a custom version and finally found the issue which was a hidden
character staying in the ups.conf file.

I rebuilt the file and everything worked out.

 

Issue closed and many thanks for your help.

 

Laurent

 

 

 

From: Jim Klimov <jimklimov+nut at gmail.com> 
Sent: mercredi 29 mars 2023 13:22
To: laurenttaieb at free.fr
Cc: nut-upsuser Mailing List <nut-upsuser at lists.alioth.debian.org>
Subject: Re: [Nut-upsuser] Question on EATON UPS

 

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

:;

 

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/247dd43e/attachment.htm>