[Nut-upsuser] upsd does not strt up

[Zoltan Farkas]

Sorry about the truss output, 

Here is the return for point 1:

# ./upsd -4 -DDD
Network UPS Tools upsd 2.1.0
listen_add: added 127.0.0.1:3493
listen_add: added 192.168.1.8:3493
setuptcp: try to bind to 127.0.0.1 port 3493
setuptcp: protocol mismatch [0]
not listening on 127.0.0.1 port 3493

Point 2, made the changes and here is the result:

# ./upsd -DDD
Network UPS Tools upsd 2.1.0
listen_add: added 127.0.0.1:3493
listen_add: added 192.168.1.8:3493
setuptcp: try to bind to 127.0.0.1 port 3493
setuptcp: protocol mismatch [0]
listening on 127.0.0.1 port 3493
setuptcp: try to bind to 192.168.1.8 port 3493
setuptcp: protocol mismatch [0]
listening on 192.168.1.8 port 3493
Connected to UPS [z2ups]: z2ups
Pinging UPS [z2ups]
UPS [z2ups]: dump is done
Got PONG from UPS [z2ups]
Pinging UPS [z2ups]
Got PONG from UPS [z2ups]
Pinging UPS [z2ups]
Got PONG from UPS [z2ups]
Pinging UPS [z2ups]
Got PONG from UPS [z2ups]
Pinging UPS [z2ups]
Got PONG from UPS [z2ups]

Regards

--zoly





-----Original Message-----
From: Arjen de Korte [mailto:nut+devel at de-korte.org] 
Sent: Monday, May 21, 2007 2:07 PM
To: Zoltan Farkas
Cc: Peter Selinger; nut-upsuser at lists.alioth.debian.org
Subject: Re: [Nut-upsuser] upsd does not strt up

Peter Selinger wrote:

>>> Forget about truss and just post the output of './upsd -DDD'.
> Could you do that, please? -- Peter

Never mind that, it's already clear to me what is wrong. After stripping
the junk that truss added, it leaves the following output:

> Network UPS Tools upsd 2.1.0 listen_add: added 127.0.0.1:3493
> listen_add: added 192.168.1.8:3493

So far, no problems. Apparently you configured 'upsd.conf' to listen to
127.0.0.1:3493 and 192.168.1.8:3493. That's probably fine, assuming
these addresses exist and no other daemons are listening there.

> setuptcp: try to bind to 127.0.0.1 port 3493 setuptcp: protocol
> mismatch [0] not listening on 127.0.0.1 port 3493

Ouch! This is unexpected. Apparently, getaddrinfo() returned one
addrinfo element, which is what we expected since we explicitly asked
for a TCP listening socket:

> hints.ai_flags	= AI_PASSIVE;
> hints.ai_family	= opt_af;
> hints.ai_socktype	= SOCK_STREAM;
> hints.ai_protocol	= IPPROTO_TCP;

But for whatever reason, it returns an addrinfo element for a IPPROTO_IP
protocol. That might be OK, but is not what we expected. POSIX is not
really clear about this:

> If ai_family is not AF_UNSPEC and ai_protocol is not zero, then
> addresses are returned for use only with the specified address family
> and protocol; the value of ai_protocol shall be interpreted as in a
> call to the socket() function with the corresponding values of
> ai_family and ai_protocol.

I would be *very* grateful if you could find the time to checkout the
following two scenarios:

1) Startup the server through

	upsd -4 -DDD

This will set the hints.ai_family to AF_INET and instructs
getaddrinfo() that the returned addrinfo element will be used for an
IPv4 listening socket). Now it should return an IPPROTO_TCP [6] addrinfo
element. See if this improves the outcome.

2) Comment out the 'continue' statements on lines 277 and 282 of the
file server/upsd.c and recompile the thing. Now start the server again
through

	upsd -DDD

This will effectively ignore a sockettype and protocol mismatch and
basically trust that whatever getaddrinfo() is returning is correct.
Since we pretty much rule out any other addrinfo elements through the
hints we gave to it, this is not necessarily a bad thing to do.

Please be kind to us mere mortals and don't use truss anymore, unless we
explicitly ask for it. It adds no useful information to us and really is
a pain to weed out the good bits.

Best regards, Arjen