Error: Connection failure: Connection refused missing context

[gpend]

The upsd error "Error: Connection failure: Connection refused" lacks much needed context. What service/process is getting refused, and what is doing the refusing?

a reference to a logfile would be helpful.

[jimklimov]

Your post lacks reference to the NUT version used :)
Something like this was addressed over recent 2.8.x releases and maybe again in what is currently on master branch and would eventually be in 2.8.3 release. To check if this specifically was addressed, you can build and install current code, see https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests

Generally, connections that upsd tries to make (and may be unsuccessful about) deal with local Unix sockets (or Windows named pipes) created and listened by each NUT driver instance. So some of your drivers are not running, and the data server on that system can not represent them via networked protocol to NUT clients.

Log files are not something NUT programs do (init scripts, systemd services, container stdout scrapers, etc. deal with that), so referring from NUT messages would be problematic and unportable. For that matter, services also are not a NUT concept but something different in every OS (although NUT does have code to try to integrate with some frameworks like systemd and SMF, where possible), and can be named by a sysadmin, so referring from built code's logs is also problematic.

Speaking of systemd or SMF, a nut-driver-enumerator service (since 2.8.0) can be running and creating units to wrap each driver separately, e.g. [email protected] - you can check journals for that, if running on recent Linux. For more context on that, see https://github.com/networkupstools/nut/wiki/nut%E2%80%90driver%E2%80%90enumerator-(NDE)

[gpend]

thank you for that.

My version is 2.7.4-13, the latest version listed in apt-get on raspbian.

The UPS I am trying to monitor is on localhost. How would I go about finding what isn't running?

[jimklimov]

FWIW, that version is about 9 years old now (it was latest formal release until 2022 though, so many stable distros still ship a variant).

One thing to check is the health and recent journal entries of services related to NUT, IIRC:

:; systemctl status nut-server nut-{monitor,client} nut-driver

NOTE: in 2.7.4 nut-driver.service was monolithic to cover all drivers at once, so fault of any impacted them all (on systems that ran several drivers)

In /etc/nut/ups.conf you can see the device configurations, including the section name and driver to run for it. You can try to systemctl stop nut-driver (to avoid conflicts of service vs. experiments) and then run /lib/nut/drivername -a sectionname -DDDDDD to start it with high debug verbosity and it may hint at what might go wrong in that part of initialization. If it does begin looping with data updates, it is likely okay though, but a paste here of the log until first "Running full update" or similar message may still be useful.