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

On 12/16/2013 08:01 PM, Charles Lepple wrote:
> On Dec 16, 2013, at 4:19 PM, David C. Rankin wrote:
> 
>> > Dec 16 14:05:16 phoinix upsd[369]: getaddrinfo: Servname not
supported for
>> > ai_socktype
> [...]
>> > The kernel update was from linux (3.12.1-3 -> 3.12.5-1), I
don't see what
>> > could have changed. How do I attempt to further debug/fix this?
> getaddrinfo(3) is a libc function - is it possible that libc was updated as
well?
> 
> I am not seeing many references to the kernel when googling for that error
message, but there was this about glib 2.18:
> 
> http://sourceware.org/ml/libc-help/2013-08/msg00023.html
Crap! You are right!

[2013-12-16 14:03] [PACMAN] upgraded glibc (2.18-10 -> 2.18-11)

How do I fix that other than downgrading?

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

On Dec 16, 2013, at 10:11 PM, David C. Rankin wrote:
> On 12/16/2013 08:01 PM, Charles Lepple wrote:
>> On Dec 16, 2013, at 4:19 PM, David C. Rankin wrote:
>> 
>>>> Dec 16 14:05:16 phoinix upsd[369]: getaddrinfo: Servname not
supported for
>>>> ai_socktype
>> [...]
>>>> The kernel update was from linux (3.12.1-3 -> 3.12.5-1), I
don't see what
>>>> could have changed. How do I attempt to further debug/fix this?
>> getaddrinfo(3) is a libc function - is it possible that libc was
updated as well?
>> 
>> I am not seeing many references to the kernel when googling for that
error message, but there was this about glib 2.18:
>> 
>> http://sourceware.org/ml/libc-help/2013-08/msg00023.html
> 
> Crap! You are right!
> 
> [2013-12-16 14:03] [PACMAN] upgraded glibc (2.18-10 -> 2.18-11)
> 
> How do I fix that other than downgrading?

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?

-- 
Charles Lepple
clepple at gmail

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.