upsd dies if upsd.conf contains LISTEN line with nonexistant ip

[bigon]

The following bug has been open in debian (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926329)

===
Dear Maintainer,

After reconfiguring 1 network interface to a new range, but forgetting to remove the last line, then one with 192.168.123.9 from /etc/nut/upsd.conf

LISTEN 127.0.0.1 3493
LISTEN 192.168.119.253 3493
LISTEN 192.168.123.9 3493

The nut daemon refused to run after it at a later date was restarted. Syslog just reported:

Apr 2 20:54:11 dkfitlet upsd[16941]: Network UPS Tools upsd 2.7.4
Apr 2 20:54:11 dkfitlet upsd[16941]: not listening on 192.168.123.9 port 3493
Apr 2 20:54:11 dkfitlet upsd[16941]: listening on 192.168.119.253 port 3493
Apr 2 20:54:11 dkfitlet upsd[16941]: listening on 127.0.0.1 port 3493
Apr 2 20:54:11 dkfitlet upsd[16941]: no listening interface available

Notice the last line message: "no listening interface available" which is not true, as 2 out of 3 configured LISTEN addresses was available. Notice also that syslog does not say that upsd exitted.

After removing the bad line from upsd.conf "LISTEN 192.168.123.9 3493" everything started working fine.

I would expect that upsd listens to the addresses it can find and not just exit.

[lienrag35]

I had the same issue and find why it refused to start :) of this can be fixed

[jimklimov]

@lienrag35 : which NUT version?

[jimklimov]

Ok, can confirm with current too:

Nov 04 17:59:14 pve nut-server[770211]: not listening on 12.34.56.78 port 3493
Nov 04 17:59:14 pve nut-server[770211]: listening on 127.0.0.1 port 3493
Nov 04 17:59:14 pve nut-server[770211]: not listening on 1.2.3.4 port 3493
Nov 04 17:59:14 pve nut-server[770211]: no listening interface available

And curiously (and inconsistently) if a working address is first, it is "okay"; if a failing one is first it aborts:

Nov 04 18:00:32 pve nut-server[790607]: Could not find PID file '/var/state/ups/upsd.pid' to see if previous upsd instance is already running!
Nov 04 18:00:32 pve nut-server[790607]: listening on 127.0.0.1 port 3493
Nov 04 18:00:32 pve nut-server[790607]: not listening on 1.2.3.4 port 3493
Nov 04 18:00:32 pve nut-server[790607]: Connected to UPS [eco650]: usbhid-ups-eco650

vs.

Nov 04 18:00:16 pve nut-server[788715]: Could not find PID file '/var/state/ups/upsd.pid' to see if previous upsd instance is already running!
Nov 04 18:00:16 pve nut-server[788715]: not listening on 12.34.56.78 port 3493
Nov 04 18:00:16 pve nut-server[788715]: listening on 127.0.0.1 port 3493
Nov 04 18:00:16 pve nut-server[788715]: no listening interface available

Not fully sure, pedantically, which one is right (e.g. from security standpoint). What do apache/nginx/etc. do?

[jimklimov]

I picked asking the audience :) (Mailing list)

[lienrag35]

@lienrag35 : which NUT version?

2.8.0

[jimklimov]

I picked asking the audience :) (Mailing list)

https://alioth-lists.debian.net/pipermail/nut-upsuser/2023-November/013479.html

[jimklimov]

So, it seems there are basically two approaches to this (NUT's non-deterministic one is wrong, better to ensure one of these two happens):

• (A) Listen to whatever interfaces we can bind to, as long as at least one is okay - proceed;
• (B) Require all listed interfaces to be usable (they were listed for a reason, right? not listening on some would get those clients not served, which is a problem best detected and fixed early - perhaps you've redefined an engineering VLAN/subnet, and need to go to all those clients to tell them to listen to their NUT server's new IP).

There are corner cases though:

• Listen on * "any address" (IPv4 and/or IPv6) AND on specific address+port endpoints - e.g. per https://forum.nginx.org/read.php?2,293645,293649#msg-293649 nginx apparently allows to proceed if specific-address listeners failed, but a catch-all on the same port succeeded. This may mean that some other program would respond on that failed address+port (same situation is possible and sometimes desired though, when one program listens on *:PORT only, and another listens on specific IP:PORT).
• Listen on string-named localhost (resolve it? or hardcode to 127.0.0.1 and/or ::1?)
• See also LISTEN * for listening with upsd on "any address" does not work with both IPv4 and IPv6 #2012 and Define upsd option to LISTEN * as specifically handling both IPv4 and IPv6 "ANY" address #2013 regarding recent NUT progress in this area.

I lean towards (B) being the more correct answer: wherever NUT was asked to listen should work; otherwise admins must roll up their sleeves ASAP. That said, I am open to having a toggle (via config file flag, maaaaybe envvar/CLI also) to allow fall back to (A) where admins are explicitly content with that (having at least some service if it is possible at all).

[opoplawski]

I push for (B) as well as providing the "least surprise". And yes, if you have an invalid server configuration you are expected to fix it.

[jimklimov]

Any takers here to walk the walk? ;)

• Refine tracking how many IP:Port sockets we have requested vs. actually managed to listen on, regardless of who was first in success/fail state (note that with * spec we can have one or two listeners for one LISTEN line; they would each be listed in the linked list of entries ultimately)
• Clarify the emitted messages, if needed
• Support some way of configuration to switch between "B" (default) and "A" behaviors

[lienrag35]

B with an explicit message as for example, some listeners are invalid