Fisher beta3 installed on K6-2 machine seems to have serious problems with resolver libraries. In short name resolution does not work regardless of a content of /etc/resolv.conf and /etc/nsswitch.conf. In particular trying to get an information from a local name server resulted in 'nslookup' and 'dig' dumping cores. Here is what 'file' has to say: core: ELF 32-bit LSB core file of 'dig' (signal 11), Intel 80386, version 1, from 'dig' and this is gdb on the same core file. (gdb) where #0 0x402def2e in __select () from /lib/libc.so.6 #1 0x4020bc84 in __DTOR_END__ () from /usr/lib/libisc.so.3 #2 0x401cca84 in pthread_start_thread (arg=0xbf3ffc00) at manager.c:274 Jakub Jelinek suggested that this may be related to #25437. Possible it is, but in this case an IP number of a name server in /etc/resolv.conf is definitely valid and none of other clients on the same network (these are various Linux, both x86 and Alpha, and Windows machines all of them using the same server) shows any troubles with a name resolution. Attempts to "strace" a command like 'host slashdot.org' do not show anything unusual and these logs make an impression that a name server is not responding (while it is responding just fine for anybody else). There are no troubles to 'ping' this server by its IP number and, after its name was added to /etc/hosts on a "stricken" machine, remote logins by name and various means (ssh, telnet, rsh) work fine without any trace of a delay. Michal michal p.s. this is filed under 'bind' because of cores from 'dig' and 'nslookup' bug quite likely this should really be 'glibc'.
This defect is considered MUST-FIX for Florence Release-Candidate #1
I havent tried the host command yet but dig is the only one that segfaults on me. nslookup works for me.
Rawhide version 9.1.0-0.4 exhibts same problems.
*** This bug has been marked as a duplicate of 25437 ***