named fails to start on boot on FreeBSD 6.1, complains about libxml2.so.5

[Mel Flynn]

On Tuesday 21 April 2009 14:21:12 Manolis Kiagias wrote:
> Mark Stosberg wrote:
> >>> We had problem with "named" starting on boot on a FreeBSD 6.1 server,
> >>> managed
> >>> by /etc/rc.conf.
> >>>
> >>> The startup script failed with errors about shared library "libm.so.2"
> >>> failing
> >>> to load because of something related to libxml2.so.5.
> >>>
> >>> Later, when I then tried starting it via /etc/rc.d/named it worked
> >>> fine.
> >>>
> >>> I include the following "ldd" output in case it's helpful. What could
> >>> possibly
> >>> be the issue here?
> >>>
> >>>    Mark
> >>>
> >>> ###
> >>>
> >>> # ldd /usr/sbin/named
> >>> /usr/sbin/named:
> >>>        libcrypto.so.4 => /lib/libcrypto.so.4 (0x281ff000)
> >>>        libxml2.so.5 => /usr/local/lib/libxml2.so.5 (0x282f1000)
> >>>        libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x283ef000)
> >>>        libm.so.4 => /lib/libm.so.4 (0x284e3000)
> >>>        libc.so.6 => /lib/libc.so.6 (0x284f9000)
> >>>        libm.so.2 => /usr/local/lib/compat/libm.so.2 (0x285d1000)
> >>
> >> I also see to LOCAL libraries in it.  named is part of base, unless you
> >> compiled and installed the port version and maybe told it to overwrite
> >> the base.
> >>
> >> None of this adds up.
> >>
> >> %ldd /usr/sbin/named
> >> /usr/sbin/named:
> >>         libcrypto.so.5 => /lib/libcrypto.so.5 (0x281fe000)
> >>         libthr.so.3 => /lib/libthr.so.3 (0x28357000)
> >>         libc.so.7 => /lib/libc.so.7 (0x2836a000)
> >>
> >> There's a named on 7.1p4
> >
> > Thanks for the response. I've now compared this named 'ldd' outfit to
> > another 6.1 install we have that also runs named. It has the exact same
> > file size and version, but slightly different ldd output:
> >
> > -- from the second machine with FreeBSD 6.1
> > # ldd /usr/sbin/named
> > /usr/sbin/named:
> >         libcrypto.so.4 => /lib/libcrypto.so.4 (0x281ff000)
> >         libxml2.so.5 => /usr/local/lib/libxml2.so.5 (0x282f1000)
> >         libz.so.3 => /lib/libz.so.3 (0x283ff000)
> >         libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x2840f000)
> >         libm.so.4 => /lib/libm.so.4 (0x284fc000)
> >         libc.so.6 => /lib/libc.so.6 (0x28512000)
> >
> > ####
> >
> > XML is still there, but the mention of libm.so no longer points into
> > /usr/local/lib/compat This other FreeBSD user also found the libxml link:
> > https://lists.isc.org/pipermail/bind-users/2008-November/073929.html
> >
> > I also checked "/etc/make.conf" on both machines. They mentioned X11_BASE
> > and Perl... nothing about XML. However, these machines have evolved some
> > over time. Perhaps something with there in the past.
> >
> > It sounds like advisable paths forward include re-compiling or
> > re-installing named.
> >
> >     Mark
>
> As it is already pointed out, you probably have a bind version installed
> from ports.
>
> Try:
>
> pkg_info -Ix bind
>
> and check if it produces anything. On a 6.4 box, the base system bind
> shows: ldd /usr/sbin/named
> /usr/sbin/named:
>     libcrypto.so.4 => /lib/libcrypto.so.4 (0x80077c000)
>     libc.so.6 => /lib/libc.so.6 (0x8009c3000)
>
> However, the port dns/bind96 for example:
>
> # pwd
> /usr/ports/dns/bind96
> # make run-depends-list
> /usr/ports/textproc/libxml2
>
> which looks suspiciously similar to your dependency there.

Agreed. Bind 9.5 and higher from ports has "XML statistics" support. That 
explains the xml and iconv. ldd -a /usr/sbin/named should show you which one 
wants libm.so.2 which is from the 4.x days.
If you don't need these statistics, I would suggest turning them off through 
make config.
-- 
Mel