Emerged sys-libs/glibc-2.3.4.20041102-r1 yesterday, today was crashing apache/php with the following error: /usr/sbin/apache2: relocation error: /lib/libnss_dns.so.2: symbol __ns_get32, version GLIBC_PRIVATE not defined in file libresolv.so.2 with link time reference The offending code is $host = @gethostbyaddr($ip); in a PHP page. Crashing isn't actually accurate, that code is in a forms processing page, and clients would get a socket closed, not sure if a thread was dying or what. Only happened if the name didn't resolve, so it worked for me and some other users. Rebuilding apache and PHP fixed the problem. Reproducible: Didn't try Steps to Reproduce: 1. Installed glibc version specified on a machine with apache2 and 2. Try to load a PHP page with the gethostbyaddr code from machine with bad reverse DNS 3. Look in apache error_log to see the error generated Actual Results: Web client got socket closed message. Expected Results: Returned the page. Installation of glibc should have either required upgrade/ rebuild of packages or notified user. Let me know if there is something that I should have seen that would do this. Also let me know if other packages that do host lookups could be affected (ie is there a better fix than rebuilding world, or should I do that? :-)
robbat: glibc is toolchain, not base-system
what version of glibc did you have before ? `emerge info` ? did you USE=nptl with older versions ?
perhaps Bug 67188 might have some useful back information
Not using ntpl emerge info: Portage 2.0.51.19 (default-linux/x86/2004.3, gcc-3.3.5, glibc-2.3.4.20041102-r1, 2.6.10-hardened-r3 i686) ================================================================= System uname: 2.6.10-hardened-r3 i686 AMD Athlon(tm) XP 2500+ Gentoo Base System version 1.4.16 Python: dev-lang/python-2.3.4-r1 [2.3.4 (#1, Feb 23 2005, 16:42:09)] dev-lang/python: 2.3.4-r1 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.8.5-r3, 1.5, 1.6.3, 1.9.4, 1.4_p6, 1.7.9-r1 sys-devel/binutils: 2.15.92.0.2-r1 sys-devel/libtool: 1.5.10-r4 virtual/os-headers: 2.4.22-r1 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms" GENTOO_MIRRORS="ftp://gentoo.mirrors.pair.com/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 apm berkdb crypt curl emboss gdbm gif ipv6 jpeg libg++ libwww mbox mp3 mysql ncurses nls pam perl php png python readline spell spl tcpd tokenizer xml2 zlib" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, PORTDIR_OVERLAY I did not try to restart apache before rebuilding (not sure why :-P). SSH works fine. Postfix works fine. 1109146622: ::: completed emerge (1 of 3) sys-libs/glibc-2.3.4.20040808-r1 to / Latest glibc emerge before this change.
"Rebuilding apache and PHP fixed the problem." Not sure if this is the case or not with glibc, but with most libraries, all software that uses that library needs to be rebuilt when the library is upgraded -> hence the revdep-rebuild utility that figures out what packages use a library and rebuild those packages.
no, glibc does not fall under that category typically you need revdep-rebuild when ABI changes; glibc is developed such that ABI is forward compat what you often have to do though is re-run an application so that versions of glibc that a process has in memory does not conflict with those that it may load later (apps that use dlload() and such)
I just updated a webserver from 2.3.2-rXX to 2.3.5, and apache/php are working fine on that system after the upgrade, so I'm going to close this unless anyone can reproduce it with 2.3.5. I know 2.3.4.XXXX had some nslookup issues, so I'm guessing whatever triggered this bug was probably fixed when that code was cleaned up.
