The client uses the 'host' command to resolve name lookups, check to see if 
that is working properly.

Yes, it seems to.

[root@localhost bin]# host us.v29.distributed.net
us.v29.distributed.net has address 204.152.189.166
us.v29.distributed.net has address 65.112.245.232
us.v29.distributed.net has address 128.104.18.148

These seems to be a bug I've commented on before, although I can't find the
original. On Mandrake 9.1 and now 9.2, the resolv.conf file is rewritten at
every boot up to put 127.0.0.1 above the other DNS entries. This causes the
error you mentioned in dnetc v2.9005-483-CFR-03032617 for Linux (Linux
2.4.22-10mdk). Changing the resolv.conf fixes the problem until the next reboot.

please test the new client v2.9007.489 from pre-release page

http://www1.distributed.net//download/prerelease.php

there are major changes which should fix the resolver problems.

This issue still occurs with the new client MDK 10.  Though it's X86, it's the
same bug.

dnetc v2.9008-490-CFR-04042310 for Linux (Linux 2.6.3-7mdk).

The original bug I raised that Ted mentioned in his post:
http://bugs.distributed.net/show_bug.cgi?id=3234

i also had this problem with mandrake 10 and dnet version:
dnetc v2.9005-483-CFR-03032617 for Linux (Linux 2.6.3-7mdksmp).
(as a temporary fix i would just run:
      dnetc -a xxx.xxx.xxx.xxx
)

it seems to work correctly after updating to the newer dnet version:
dnetc v2.9008-490-CFR-04042310 for Linux (Linux 2.6.3-7mdksmp).

dnetc v2.9007-486-CFR-03110904 for Linux (Linux 2.6.8-SMP-rc1+BK@1.1416).

It works only if nscd is enabled and a link to correct socket file is made at 
the old location... /var/run/nscd/socket is where it lives on FC2.  Without 
nscd, the client does everything it's supposed except actually making a DNS 
query. (resolv.conf and nsswitch.conf are consulted and the correct libnss 
libraries load)

For what it's worth, on my redhat8 machines, I did not have 'bind' installed. 
I
did 'up2date install bind' and this installed the 'host' command, allowing me
to
flush my buffers.

Maybe a fix would be a dependency check for 'bind' or the 'host' command before
building?

Gabriel

http://n0cgi.distributed.net/faq/cache/43.html

The above FAQ-o-Matic states the following:

"More recently, starting in v2.9008-490 the Linux client is now statically
compiled with ucLibc (instead of glibc) and no longer has any dependencies on
the "host" utility. The only requirement is that your /etc/resolv.conf be
properly configured with valid nameservers."

This does not appear to be the case:

rpao@ca810e:~/bin/distributed.net/dnetc491-linux-x86-elf$ ping
us.v29.distributed.net -c 1
PING us.v29.distributed.net (128.104.18.148) 56(84) bytes of data.
64 bytes from speed.doit.wisc.edu (128.104.18.148): icmp_seq=1 ttl=51 time=66.1
ms

--- us.v29.distributed.net ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 66.189/66.189/66.189/0.000 ms
rpao@ca810e:~/bin/distributed.net/dnetc491-linux-x86-elf$ ./dnetc -update       
distributed.net client for Linux Copyright 1997-2004, distributed.net
Please visit http://www.distributed.net/ for up-to-date contest information.


dnetc v2.9008-491-CFR-04052900 for Linux (Linux 2.6.11.7-chw-3).
Please provide the *entire* version descriptor when submitting bug reports.
The distributed.net bug report pages are at http://www.distributed.net/bugs/
Using email address (distributed.net ID) 'rpao-distributed.net@paonet.org'

[May 27 14:01:04 UTC] Net::failed to resolve name "us.v29.distributed.net"
                      ENOENT: No such file or directory
                      Perhaps the 'host' command was not found?
[May 27 14:01:04 UTC] Network update is currently not available.
[May 27 14:01:04 UTC] Buffer update failed.
rpao@ca810e:~/bin/distributed.net/dnetc491-linux-x86-elf$ host
us.v29.distributed.net
-bash: host: command not found

It could be argued that installing Bind/host would solve this problem; however,
I am unwilling to modify this KnoppMyth R5A15 box more than I have to.  I wipe
it every few months.  Besides, the FAQ says 'host' is not called anyway for the
client version I am using.

This bug is recurring in systems running Ubuntu 7.10.

Reported by tiogshi:
[tiogshi@neptune ~/.dnet]$ ./dnetc

distributed.net client for Linux Copyright 1997-2005, distributed.net
Please visit http://www.distributed.net/ for up-to-date contest information.

dnetc v2.9011-496-CFR-05060814 for Linux (Linux 2.6.22-14-generic).
Please provide the *entire* version descriptor when submitting bug reports.
The distributed.net bug report pages are at http://www.distributed.net/bugs/
Using email address ( distributed.net ID) <>

[Nov 16 21:10:00 UTC] Automatic processor detection found 2 processors.
[Nov 16 21:10:00 UTC] Loading crunchers with work...
[Nov 16 21:10:00 UTC] Attempting to resolve 'us.v29.distributed.net'...Floating
point exception (core dumped)

Also reported by arafnord:

dnetc v2.9011-496-CFR-05060814 for Linux (Linux 2.6.22-14-rt).
[Dec 09 15:54:29 UTC] Attempting to resolve
'euro.v29.distributed.net'...Floating point exception (core dumped)

Arafnord has reported that removing the libnss-mdns (multicast dns) library has
fixed the problem he was experiencing running dnetc on Ubuntu 7.10.

The command for this is:-
sudo aptitude remove libnss-mdns

Seems to be amd64 compiler incompatibility issue, due to dnetc is shipped as a
binary. Workaround is to remove libnss-mdns package if you don't need it.

Here is the link to Ubuntu bugzilla entry:
https://bugs.edge.launchpad.net/debian/+source/distributed-net/+bug/134056

*** This bug has been marked as a duplicate of 4002 ***

*** Bug 4041 has been marked as a duplicate of this bug. ***