Unsatisfied data symbol 'rfc931_timeout'

[Ralph Grothe]

Hi,

this is related to my other thread:
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1178957

Hoped to draw more attention by initiating a 2nd thread cause this isn't a strict Nagios/NRPE problem but maybe a compiler issue on IA64 B.11.23

I compiled the nrpe daemon with a 32Bit gcc on this platform:

$ uname -srm
HP-UX B.11.23 ia64

$ /usr/local/bin/gcc --version
gcc (GCC) 4.1.2
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

When I try to execute the built nrpe daemon
I get this error message:

/usr/lib/hpux32/dld.so: Unsatisfied data symbol 'rfc931_timeout' in load module '/usr/lib/hpux32/libwrap.so'.


These are build dependencies:

$ chatr /opt/iexpress/nagios/bin/nrpe
/opt/iexpress/nagios/bin/nrpe:
32-bit ELF executable
shared library dynamic path search:
LD_LIBRARY_PATH enabled first
SHLIB_PATH enabled second
embedded path enabled third /usr/local/lib/gcc/ia64-hp-hpux11.23/4.1.2:/usr/ccs/lib:/usr/local/lib/gcc/ia64-hp-hpux11.23/4.1.2/../../..
shared library list:
libnsl.so.1
libwrap.so
libc.so.1
shared library binding:
deferred
global hash table disabled
global hash table size 1103
shared library mapped private disabled
shared library segment merging disabled
shared vtable support disabled
explicit unloading disabled
linkage table protection disabled
segments:
index type address flags size
8 text 04000000 z---c- D (default)
9 data 40010000 ---m-- D (default)
executable from stack: D (default)
kernel assisted branch prediction enabled
lazy swap allocation for dynamic segments disabled
nulptr references enabled
address space model: default
caliper dynamic instrumentation disabled


Interestingly the built check_nrpe program from the same build works satisfactorily.

$ /opt/iexpress/nagios/libexec/check_nrpe -H somehost -c check_syslog_VMUNIX
OK - No matches found.


Does anyone have a clue how to satisfy the symbol rfc932_timeout?

Rgds
Ralph

[Jaime Bolanos Rojas.]

Ralph,

This is just a though, did you make sure that the rfc931_timeout is enable in the tcpd.conf file?

Regards,

Jaime.

[Ralph Grothe]

Hi Jaime,

a good hint.
I never have used 11.23 before.
Therefore I wasn't aware that unlike our usual 11.11 this OS seems to have integrated a tcp wrapper already.

On this IA box I cannot find a tcpd.conf file however.

# ll /etc/tcpd.conf
/etc/tcpd.conf not found

So I assume that according to man tcpd.conf the default of rfc931_timeout n is assumed,
should the tcp wrapper be in effect at all.

I created the file with these entries for a start

# cat /etc/tcpd.conf
rfc931_timeout 15
log_level extended


Then I defined nrpe as new service for inted
passing control to the tcpwrapper.

# grep nrpe /etc/inetd.conf
nrpe stream tcp nowait nagios /usr/lbin/tcpd /opt/iexpress/nagios/bin/nrpe -c /opt/iexpress/nagios/etc/nrpe.cfg --inetd

nrpe binary is in place an executable

# ll /opt/iexpress/nagios/bin/nrpe
-rwxr-xr-x 1 root sys 185972 Nov 22 12:55 /opt/iexpress/nagios/bin/nrpe

so is the nrpe.cfg

# ll /opt/iexpress/nagios/etc/nrpe.cfg
-rw-r--r-- 1 root sys 7107 Nov 22 15:13 /opt/iexpress/nagios/etc/nrpe.cfg

User nagios was automatically created on swinstall of the IExpress Nagios depot
that *lacked* the nrpe binary.

# id nagios
uid=112(nagios) gid=106(nagios)

Also registered the port with services

# grep nrpe /etc/services
nrpe 5666/tcp # Nagios Remote Plugin Executor


and sent inetd a SIGHUP
(also issued /usr/sbin/inetd -s
for some extended logging)

nrpe bound listening socket

# netstat -anfinet|grep 5666
tcp 0 0 *.5666 *.* LISTEN


For a start try to run this check

# /opt/iexpress/nagios/libexec/check_nrpe -H 127.0.0.1 -c check_load
CHECK_NRPE: Received 0 bytes from daemon. Check the remote server logs for error messages.

Hm, path to this check is ok
and it can be executed by user nagios

# grep ^command.*check_load /opt/iexpress/nagios/etc/nrpe.cfg
command[check_load]=/opt/iexpress/nagios/libexec/check_load -w 15,10,5 -c 30,25,20


# su - nagios -c "/opt/iexpress/nagios/libexec/check_load -w 15,10,5 -c 30,25,20" 2>/dev/null|tail -2
OK - load average: 0.03, 0.08, 0.10|load1=0.030;15.000;30.000;0; load5=0.080;10.000;25.000;0; load15=0.100;5.000;20.000;0;
logout

A mere "Permission denied" is a bit terse though despite extended logging.


# tail -2 /var/adm/syslog/syslog.log
Nov 22 15:31:16 shrek inetd[25048]: nrpe/tcp: Connection from 127.0.0.1 at Thu Nov 22 15:31:16 2007
Nov 22 15:31:16 shrek inetd[25048]: exec /usr/lbin/tcpd: Permission denied


Something else to consider for tcpd or other wrappers that I forgot?

[Dennis Handly]

>maybe a compiler issue on IA64 B.11.23

Not hardly, perhaps linker/dld or a missing patch, libc or libnsl?

>Does anyone have a clue how to satisfy the symbol rfc932_timeout?

Can you scan your sources of what you built? Did you build libwrap?

You could scan all your libs to see if it is elsewhere:
$ nm -pxAN /usr/lib/hpux32/lib* | grep rfc932_timeout

>Interestingly the built check_nrpe program from the same build works satisfactorily.

How to do you know? Can you provide the chatr(1) shared library list?
If it shows libwrap.so and no new shlibs, it is all an illusion.

[Ralph Grothe]

Hi Dennis,

grepping the symbol tables of all library object files within /usr/lib/hpux32 for rfc931_timeout, as you suggested, produces no match.

# nm -ANpx /usr/lib/hpux32/lib*|grep rfc932_timeout
nm: /usr/lib/hpux32/lib.b: bad magic
nm: /usr/lib/hpux32/libc_symbols: bad magic
no symbols
no symbols
no symbols
no symbols
no symbols
no symbols
no symbols
no symbols
no symbols
no symbols
no symbols
no symbols
nm: /usr/lib/hpux32/libp: bad magic
no symbols
no symbols
no symbols
no symbols
no symbols
no symbols


How did I know check_nrpe worked?
Well, I simply ran a check_nrpe against another NRPE host and got the expected output and return code.

Here's the chatr output on the check_nrep that I compiled by the same make that produced the strange behaving nrpe binary.

# chatr /opt/iexpress/nagios/libexec/check_nrpe
/opt/iexpress/nagios/libexec/check_nrpe:
32-bit ELF executable
shared library dynamic path search:
LD_LIBRARY_PATH enabled first
SHLIB_PATH enabled second
embedded path enabled third /usr/local/lib/gcc/ia64-hp-hpux11.23/4.1.2:/usr/ccs/lib:/usr/local/lib/gcc/ia64-hp-hpux11.23/4.1.2/../../..
shared library list:
libnsl.so.1
libc.so.1
shared library binding:
deferred
global hash table disabled
global hash table size 1103
shared library mapped private disabled
shared library segment merging disabled
shared vtable support disabled
explicit unloading disabled
linkage table protection disabled
segments:
index type address flags size
8 text 04000000 z---c- D (default)
9 data 40010000 ---m-- D (default)
executable from stack: D (default)
kernel assisted branch prediction enabled
lazy swap allocation for dynamic segments disabled
nulptr references enabled
address space model: default
caliper dynamic instrumentation disabled



From the config.log of the configure run of nrpe I can see lots of unsatisfied symbols


# grep -in unsatis /usr/local/src/nrpe-2.10/config.log
1023:ld: Unsatisfied symbol "asprintf" in file /var/tmp//ccMzYWPc.o
1126:ld: Unsatisfied symbol "vasprintf" in file /var/tmp//ccv4xxQc.o
1316:ld: Unsatisfied symbol "getopt_long" in file /var/tmp//ccJebaOb.o
1511:ld: (Warning) Unsatisfied symbol "t_rcvudata" in file /usr/lib/hpux32/libwrap.so
1512:ld: (Warning) Unsatisfied symbol "t_alloc" in file /usr/lib/hpux32/libwrap.so
1513:ld: (Warning) Unsatisfied symbol "t_errno" in file /usr/lib/hpux32/libwrap.so
1514:ld: (Warning) Unsatisfied symbol "taddr2uaddr" in file /usr/lib/hpux32/libwrap.so
1515:ld: (Warning) Unsatisfied symbol "netdir_free" in file /usr/lib/hpux32/libwrap.so
1516:ld: (Warning) Unsatisfied symbol "t_errlist" in file /usr/lib/hpux32/libwrap.so
1517:ld: (Warning) Unsatisfied symbol "deny_severity" in file /usr/lib/hpux32/libwrap.so
1518:ld: (Warning) Unsatisfied symbol "freenetconfigent" in file /usr/lib/hpux32/libwrap.so
1519:ld: (Warning) Unsatisfied symbol "t_free" in file /usr/lib/hpux32/libwrap.so
1520:ld: (Warning) Unsatisfied symbol "t_nerr" in file /usr/lib/hpux32/libwrap.so
1521:ld: (Warning) Unsatisfied symbol "netdir_getbyaddr" in file /usr/lib/hpux32/libwrap.so
1522:ld: (Warning) Unsatisfied symbol "allow_severity" in file /usr/lib/hpux32/libwrap.so
1523:ld: (Warning) Unsatisfied symbol "yp_get_default_domain" in file /usr/lib/hpux32/libwrap.so
1524:ld: (Warning) Unsatisfied symbol "t_sync" in file /usr/lib/hpux32/libwrap.so
1525:ld: (Warning) Unsatisfied symbol "getnetconfig" in file /usr/lib/hpux32/libwrap.so
1526:ld: (Warning) Unsatisfied symbol "setnetconfig" in file /usr/lib/hpux32/libwrap.so
1527:ld: (Warning) Unsatisfied symbol "getnetconfigent" in file /usr/lib/hpux32/libwrap.so
1528:ld: (Warning) Unsatisfied symbol "netdir_getbyname" in file /usr/lib/hpux32/libwrap.so
1529:ld: (Warning) Unsatisfied symbol "t_getprotaddr" in file /usr/lib/hpux32/libwrap.so
1530:ld: (Warning) Unsatisfied symbol "nc_sperror" in file /usr/lib/hpux32/libwrap.so
1531:ld: (Warning) Unsatisfied symbol "rfc931_timeout" in file /usr/lib/hpux32/libwrap.so
1580:ld: Unsatisfied symbol "closesocket" in file /var/tmp//ccSEaOyc.o


This ominous shared libwrap is part of the InternetSrvcs fileset that was already installed on this box.
Does HP offer a patch which introduces the unsatisfied symbols?

# swlist -l file|grep libwrap
InternetSrvcs.INETSVCS-WRAP: /usr/lib/hpux32/libwrap.so
InternetSrvcs.INETSVCS-WRAP: /usr/lib/hpux32/libwrap.so.1

[Dennis Handly]

>grepping the symbol tables of all library object files within /usr/lib/hpux32 for rfc931_timeout, as you suggested, produces no match.

You may have to look in more paths? But if HP shipped that lib, I guess not.

>no symbols

If you get a lot of these, you'll have to replace nm by:
elfdump -s -n .dynsym
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1094016

>Here's the chatr output on the check_nrep
>shared library list: libnsl.so.1 libc.so.1

That's why it "works", it doesn't use the "broken" libwrap.

>From the config.log of the configure run of nrpe I can see lots of unsatisfied symbols

Whatever command/option that is producing these is broken. It isn't giving you any useful info except for rfc931_timeout. Most of these are defined in libnsl.

>This ominous shared libwrap is part of the InternetSrvcs fileset that was already installed on this box.

Ok, using google I found these links that describes what libwrap does:
http://docs.hp.com/en/B2355-91060/ch03s03.html
http://software.hp.com/portal/swdepot/displayProductInfo.do?productNumber=TCPWRAP
http://docs.hp.com/en/5991-4837/ch01s01.html
http://docs.hp.com/en/5991-4837/5991-4837.pdf
http://docs.hp.com/en/B2355-90774/B2355-90774.pdf
http://docs.hp.com/en/5991-4837/ch03s01.html
http://docs.hp.com/en/B2355-60130/hosts_access.3.html

The last is a man page for libwrap and includes rfc931_timeout.
It doesn't say you have to link with libwrap.a instead of libwrap.so. You could experiment by changing your link line to use -l:libwrap.a.

The man page doesn't say that you must define that variable in your application. You could change your source to define that variable.

>Does HP offer a patch which introduces the unsatisfied symbols?

Not sure. A quick search of the patch database doesn't find libwrap, rfc931_timeout, InternetSrvcs or INETSVCS-WRAP.

You should probably contact the Response Center and file a bug report.

[Ralph Grothe]

Hi Dennis,

sorry for the belated feedback and the measly 7 pts (don't want a solved signifying bunny to appear, so please do any idle posting that I can asign you another 7 pts)

Have had too little time lately to carry on,
but problem still lingering for solution.

Meanwhile sent an email to InternetExpress Team, asking them to include NRPE and NSCA with one of their next IE releases.

[Dennis Handly]

>but problem still lingering for solution.

It appears libwrap is broken. Or the documentation is.
libwrap has an unsat for rfc931_timeout that nobody defines.
The only way to get it to work is to define your own int rfc931_timeout.
And it is still broken on 11.31.

[Dennis Handly]

Looking at the source, rfc931.c, indicates it has been broken since 2002 or even earlier.

[Dennis Handly]

Did you report the problem with libunwrap?
Did you try the workaround I mentioned?
It appears about 3 other threads mentioned this rfc932_timeout unsat.