After updating glibc and ucspi-tcp I had to reboot and kept getting this message in the qmail-smtpd log @40000000426f39c81d15f9ec tcpserver: fatal: temporarily unable to figure out IP address for 0.0.0.0: file does not exist Using strace, the missing file was /etc/dnsrewrite Doing touch /etc/dnsrewrite solved the problem. I am not sure if this is a problem with the glibc 2.3.5 or ucspi-tcp-0.88-r10. Recompiling ucspi-tcp after glibc didn't solve it. Reproducible: Always Steps to Reproduce: hammer etc # emerge --info Portage 2.0.51.20-r4 (default-linux/amd64/2004.3, gcc-3.4.3-20050110, glibc-2.3.5-r0, 2.6.11-gentoo-r6 x86_64) ================================================================= System uname: 2.6.11-gentoo-r6 x86_64 AMD Opteron(tm) Processor 244 Gentoo Base System version 1.6.10 distcc 2.18 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] dev-lang/python: 2.2.3-r5, 2.3.5 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r8 sys-devel/libtool: 1.5.14 virtual/os-headers: 2.6.11 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=athlon64 -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/bind /var/qmail/alias /var/qmail/control /var/vpopmail/domains /var/vpopmail/etc" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig collision-protect distlocks sandbox strict" GENTOO_MIRRORS="ftp://gentoo.risq.qc.ca/ http://mirror.datapipe.net/gentoo" MAKEOPTS="-j4" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X aalib acpi adns alsa amd64 apache2 arts avi berkdb bitmap-fonts crypt cups curl dvd edl encode extensions flash font-server fortran gd gdbm gif gpm gtk imagemagick imap innodb java jp2 jpeg justify libcaca libwww live lzo lzw lzw-tiff mad mailwrapper matroska mcal mikmod mp3 multilib mysql mythtv ncurses network nls no-htdocs ogg opengl oss pam pdflib perl png python qt quicktime readline rtc sdl skey slang ssl tcltk tcpd tga theora tiff truetype truetype-fonts type1-fonts usb userlocales vorbis xanim xml2 xmms xpm xrandr xv xvid zlib" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
tcpserver refers to /etc/dnsrewrite, not glibc
are you sure your dns is setup properly ? i run qmail on a bunch of machines and ive never seen that error / had this problem what does `ping 0.0.0.0` show ?
hammer ~ # ping 0.0.0.0 PING 0.0.0.0 (127.0.0.1) 56(84) bytes of data. 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.054 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.024 ms --- 0.0.0.0 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1000ms rtt min/avg/max/mdev = 0.024/0.039/0.054/0.015 ms Have you tried updating ucspi-tcp. Though as I said, creating an empty /etc/dnsrewrite worked However there is no indication that this is needed for ucspi to work.
ucspi-tcp-0.88-r10 has been in portage for a few months now and yes i've been using that without issue if you downgrade to 0.88-r9 or 0.88-r8 and restrat svscan, does this error still occur ?
Yes it still happens.
err hrm, i can reproduce this, but just on my glibc-2.3.5 machines ;) i'll debug it some more
actually, i can reproduce this just fine if i remove 'search' lines from /etc/resolv.conf ... for example, my resolv.conf just says: nameserver 192.168.0.1 if i just do `echo search >> /etc/resolv.conf`, tcpserver starts working again
No response in a long time. Closing as WFM.
As a followup comment on this, I just ran into it on an amd64 box as well. It occured with any of the -O[23s] optimization flags, but not with -O1. I didn't test the /etc/dnsrewrite or search line for resolv.conf ideas, but I just changed the ebuild to force -O1 as a more global solution.
so why did you comment on a closed bug rather than re-opening or filing a new one
vapier: because I already fixed the problem before I found this bug - it was only somebody else pointing this one out to me that I thought it worth leaving a comment.
forcing building at -O1 is not a fix
