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.
>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 :)
_______________________________________________ Nut-upsuser mailing list Nut-upsuser@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser