Nut upsdev - Dec 2013 - SOLVED Re: kernel update to 3.12.5-1, now: upsd[617]: getaddrinfo: Servname not supported for ai_socktype

On 12/16/2013 09:23 PM, Charles Lepple wrote:
> Not sure - I didn't write the getaddrinfo() code in upsd, but it seemed
to
> follow all of the recommendations on how to use that function. So if there
is
> a way to fix it in the NUT code, I am not aware of it (and would appreciate
> any updates if that turns out to be the case).
> 
> The odd part is that it looks like you went from one Arch revision of glibc
> from 2.18 to 2.18, and most of the mailing list posts I saw while googling
> were regressions going from 2.17 to 2.18. But this is making a bunch of
> assumptions about the kind of changes that might creep in between -10 and
> -11.
> 
> You aren't mixing 32- and 64-bit userspace libraries, are you?
> 
  No, something is messed up in server/upsd.c, but I haven't a clue why. I
modified upsd.c to dump the getaddrinfo parameter to the error log. Beginning
line 192:

        if ((v = getaddrinfo(server->addr, server->port, &hints,
&res)) != 0) {
            fprintf(stderr, "=========== Error Block Hit
============\n");
            fprintf(stderr, "getaddrinfo               :  %s\n",
gai_strerror(v));
            fprintf(stderr, "Server addr (Nodename)    :  %s\n",
server->addr);
            fprintf(stderr, "Server port (Servname)    :  %s\n",
server->port);
            fprintf(stderr, "hints.ai_flags            :  %d\n",
hints.ai_flags);
            fprintf(stderr, "hints.ai_family           :  %d\n",
hints.ai_family);
            fprintf(stderr, "hints.ai_socktype         :  %d\n",
hints.ai_socktype);
            fprintf(stderr, "hints.ai_protocol         :  %d\n",
hints.ai_protocol);

                if (v == EAI_SYSTEM) {
                        fatal_with_errno(EXIT_FAILURE, "getaddrinfo");
                }

                fatalx(EXIT_FAILURE, "getaddrinfo: %s",
gai_strerror(v));
        }

I rebuilt nut and ran it, the error log contained:

Dec 17 10:21:01 phoinix upsd[27151]: =========== Error Block Hit ===========Dec
17 10:21:01 phoinix upsd[27151]: getaddrinfo               :  Servname not
supported for ai_socktype
Dec 17 10:21:01 phoinix upsd[27151]: Server addr (Nodename)    :  192.168.7.16
Dec 17 10:21:01 phoinix upsd[27151]: Server port (Servname)    :  :3493
Dec 17 10:21:01 phoinix upsd[27151]: hints.ai_flags            :  1
Dec 17 10:21:01 phoinix upsd[27151]: hints.ai_family           :  0
Dec 17 10:21:01 phoinix upsd[27151]: hints.ai_socktype         :  1
Dec 17 10:21:01 phoinix upsd[27151]: hints.ai_protocol         :  6

  Huh? Why the : in Servname? So I just hardwired it passing the port
"Servname"
as "3493" (could have just used "nut" from /etc/services):

        if ((v = getaddrinfo(server->addr, "3493", &hints,
&res)) != 0) {

  I rebuilt nut again and --> BINGO! It started working again just fine. So
the
whole problem was something is causing the 'Servname' to be passed with
a
leading ':' when passed with the 'server->port' parameter in
the getaddrinfo
call at line 192 of upsd.c

  I have NO CLUE what could have changed in the updated packages that cause the
':' to be prepended to server->port, but it is happening. Where do we
go from
here to fix it.

  Also, my systemd/system/nut-driver.service file is being generated with the
following:

[Service]
ExecStart=/upsdrvctl start
ExecStop=/upsdrvctl stop
Type=forking

  That obviously fails. Where did the /usr/bin go before the /upsdrvctl?

  Are both these git issues?


-- 
David C. Rankin, J.D.,P.E.

On 12/17/2013 10:43 AM, David C. Rankin wrote:
>   Huh? Why the : in Servname? So I just hardwired it passing the port
"Servname"
> as "3493" (could have just used "nut" from
/etc/services):
Sheepishly looking for a place to hide....

  Yes there was a ':' there all right. Seems I was hit by a vi error:

[12:04 phoinix:/etc/ups] # grep 3493 *.conf
upsd.conf:LISTEN 127.0.0.1 3493
upsd.conf:LISTEN ::1 3493
upsd.conf:LISTEN 192.168.7.16 :3493

GRRR!  I hate it when that happens.

Sorry for the noise...


-- 
David C. Rankin, J.D.,P.E.

Now hold on there...

you said the problem started when you updated kernels - not when
you changed the config file - did you change the config file or was
it wrong before and the old kernel accepted it anyway?

ted

On 12/17/2013 10:08 AM, David C. Rankin wrote:
> On 12/17/2013 10:43 AM, David C. Rankin wrote:
>>    Huh? Why the : in Servname? So I just hardwired it passing the port
"Servname"
>> as "3493" (could have just used "nut" from
/etc/services):
>
> Sheepishly looking for a place to hide....
>
>    Yes there was a ':' there all right. Seems I was hit by a vi
error:
>
> [12:04 phoinix:/etc/ups] # grep 3493 *.conf
> upsd.conf:LISTEN 127.0.0.1 3493
> upsd.conf:LISTEN ::1 3493
> upsd.conf:LISTEN 192.168.7.16 :3493
>
> GRRR!  I hate it when that happens.
>
> Sorry for the noise...
>
>

On Dec 17, 2013, at 1:08 PM, David C. Rankin wrote:
> On 12/17/2013 10:43 AM, David C. Rankin wrote:
>>  Huh? Why the : in Servname? So I just hardwired it passing the port
"Servname"
>> as "3493" (could have just used "nut" from
/etc/services):
> 
> Sheepishly looking for a place to hide....
> 
>  Yes there was a ':' there all right. Seems I was hit by a vi
error:
> 
> [12:04 phoinix:/etc/ups] # grep 3493 *.conf
> upsd.conf:LISTEN 127.0.0.1 3493
> upsd.conf:LISTEN ::1 3493
> upsd.conf:LISTEN 192.168.7.16 :3493
> 
> GRRR!  I hate it when that happens.
Thanks for taking the time to track this down. It's another thing we need to
add to the list of areas that need better debug messages.

-- 
Charles Lepple
clepple at gmail

On Dec 17, 2013, at 11:43 AM, David C. Rankin wrote:
>  Also, my systemd/system/nut-driver.service file is being generated with
the
> following:
> 
> [Service]
> ExecStart=/upsdrvctl start
> ExecStop=/upsdrvctl stop
> Type=forking
> 
>  That obviously fails. Where did the /usr/bin go before the /upsdrvctl?
Lovely. We must have introduced an error somewhere in autoconf. What does the
./configure... line say in the beginning of config.log? (If you don't have
config.log handy, what parameters is your packaging system using?)

-- 
Charles Lepple
clepple at gmail