Re: Problem: Distributed-net on Sparc
On 15 Aug 2001 12:45:31 -0500, Russell D Cook wrote:
> Debian is 2.2r2, upgraded to testing/unstable.
> Kernel is 2.2.18pre21.
> Library is libc-2.2.3-9.
>
>
>
> Michael Heldebrant wrote:
>
> > On 15 Aug 2001 12:06:46 -0500, Russell D Cook wrote:
> > > I installed the debian package - I figured there would be less likelihood
> > > of problems that way. Thanks for the reply.
> > > Still need help.
> > >
> > > Regards,
> > > Russ
> > >
> > > Michael Heldebrant wrote:
> > >
> > > > On 15 Aug 2001 11:40:16 -0500, Russell D Cook wrote:
> > > > > I have 3 Sparcs running Debian unstable/testing. I recently installed
> > > > > distributed-net from a Debian package. The software is running on
> > > > > the three machines, but the log files are filled with the following
> > > > > message:
> > > > > Network::failed to resolve name "us.v27.distributed.net"
> > > > > The machines have no problem with ftp or http access to the net, and
> > > > > are on a lan. The package runs fine on my x86 boxes at home. Is there
> > > > > some peculiarity about the distributed-net package with the Sparc
> > > > > distribution?
> > > > >
> > > > > Any help gratefully accepted: I'm storing up many random keys to check
> > > > > in.
> > > > >
> > > >
> > > > I once ran into that exact same problem when I was running a glibc
> > > > version of distnet on a libc system. Did you install the debian package
> > > > or put your own?
> >
> > What version of libc6 (which dselect says it depends on) is the system
> > running? What release of debian are you running?
Perhaps some previous users have solved it in one way or another for you
below.
Blatantly stolen from the distributed.net faq-o-matic:
The most common reason is because you are located behind a firewall and
the client can't get directly out to the internet. There are work
arounds as described in the next section. Intermittent network errors
can also occur due to poor conditions on your LAN, poor phone lines, or
heavy traffic on the internet itself. There have been some problems with
earlier versions of the client being overly sensitive to response times.
These problems have been mostly resolved.
If you are getting "Unable to resolve..." messages from the Linux
client, you may be having a compatibility problem with the "glibc"
library. There are two common, incompatible versions of glibc: glibc2.0
and glibc2.1. You will notice that there are two Linux clients with
"glibc20" and glibc21" in their file names. You must choose the correct
version in order for name resolution to work. If you are not sure which
glibc version you have, just try the other client to see if it works
better.
Starting with build v2.8008-459 of the client, there are now be a single
unified Linux binary (for each processor architecture type), instead of
separate ones for each architecture and library combination. The name
resolution incompatibilities have been worked around by using "clever"
dynamic symbol loading techniques, but this didn't work very well
(problems ranged from segfaults to hanging threads to simply
not-working).
So, from 2.8011-463 on, the client does not even bother trying to work
around the insanity introduced by glibc, and instead pipes/parses the
output of 'host'.
I noticed that (at least on Unix) a running client does not take any
notice if you change DNS servers. Look out for spurious UDP packets to
the old nameserver (netstat -tn), and a failure to flush buffers once
the old nameserver has packed up and gone home. Restarting the client
will fix this. This applies to any application that uses the ISC
resolver, which only loads /etc/resolv.conf (into static storage) once.
If you find that your Linux client is reporting this error, it's because
you do not have the bind tools installed on your computer. Look for a
"bind-tools" binary package in whichever packaging format is appropriate
for your particular flavor of linux.
Unfortunately, the only alternative to requiring bind-tools would be for
distributed.net to release multiple, conflicting versions of the client
for all the various libc permutations that exist.
To simply set the address manually, also solves the problem. By using
nslookup or ping, I found the IP address of the name it failed to
resolve. Then it was just to start the client with:
dnetc -a 145.89.128.249
If they change the ip address, or that server goes down, the client will
fail. So I have the client running in a detached screen. And I check the
output from time to time.
Reply to: