Open jimklimov opened 7 months ago
For kicks, tried if it would just work - no, it does not; the whole single/first token is seen as an address, and the lack of second token causes an attempt to use the default port number:
:; rm -rf /tmp/nnnn ; mkdir -p /tmp/nnnn && touch /tmp/nnnn/{ups.conf,upsd.conf,upsd.users}
:; echo 'LISTEN :::3493' > /tmp/nnnn/upsd.conf
:; ALLOW_NO_DEVICE=yes NUT_STATEPATH=/tmp/nnnn NUT_CONFPATH=/tmp/nnnn ./server/upsd -DDDDDD ; echo $?
Network UPS Tools upsd 2.8.2-137-g3c19d79de
0.000001 fopen /tmp/nnnn/upsd.pid: No such file or directory
0.000043 Could not find PID file '/tmp/nnnn/upsd.pid' to see if previous upsd instance is already running!
0.000208 /tmp/nnnn/upsd.conf is world readable
0.000333 [D3] listen_add: added :::3493:3493
0.000373 [D1] debug level is '6'
0.000413 [D3] setuptcp: try to bind to :::3493 port 3493
0.000530 getaddrinfo: Name or service not known
Thinking of it... might make sense to parse a single token on a
LISTEN <token1>:<token2>
(with at least one colon character), as anaddr
-colon-port
so spelling ofLISTEN :::3493
would get split into::
and3493
, and someLISTEN 127.0.0.1:3493
would become127.0.0.1
and3493
.That said, in ~25 years of NUT's existence I think this is the first time such issue was raised (to the best of my personal knowledge) - so I guess it is a rare surprise after all the RTFM :)
Originally posted by @jimklimov in https://github.com/networkupstools/nut/issues/2417#issuecomment-2081668113
UPDATE: This could be easy in the server-side code; most of the problem would be to teach
nutconf
,augeas
and similarupsd.conf
parsers about two acceptable spellings.UPDATE: While at it (although a separate issue): is there any perceived need to parse the
port
part (if its string is not representing a number) through the naming database for services to e.g.LISTEN localhost nut
?CC @aquette @clepple : WDYT ?