<div dir="ltr"><div dir="ltr"><div>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@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.</div><div><br></div><div>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.</div><div><br></div><div>As for the "infinite loop" - yes, that's what NUT drivers do as their day job :)</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.:<br><br>
<span lang="EN-US">:; sudo /usr/lib/nut/usbhid-ups -a myups3 -DDD</span> -d1</div></div><div><br></div><div>Hope this helps,</div><div>Jim</div><div><br></div><div>PS: Better not post screenshots as images to mailing lists, if that can be avoided by posting texts/archives of those :)</div><div> </div></div>