[distcc] distcc problems...

ahasty at chiaro.com ahasty at chiaro.com
Thu Mar 11 00:35:36 GMT 2004


I pursued the DISTCC_DIR angle first.
I think by default this environment variable is set to your $HOME/.distcc directory which in our setup is NFS mounted on a Netapps box. 
While I have only run the test ONCE, setting the DISTCC_DIR=/tmp/ahasty/.distcc resulted in a clean run. 
I will try this several more times, to see if it really cleans up the problem. 
I do have distccmon-text running on each of the machines that the  make is run on, just to see what is going on. 
I'll try this several more times tomorrow and report back the problems. 

Thanks for your help. 
Alan Hasty
Chiaro Networks 

-----Original Message-----
From: Daniel Kegel [mailto:dank at kegel.com]
Sent: Wednesday, March 10, 2004 5:28 PM
To: Martin Pool
Cc: Daniel Kegel; Alan Hasty; distcc at lists.samba.org
Subject: Re: [distcc] distcc problems...


Martin Pool wrote:
> If he's running distccmon-text then he is attempting to make use of
> them.

gah, I missed that.

> ...  But a similar technique is used for
> lock files, which are not optional.  If your filesystem is flaking
> out, there may be more problems than just the monitor failing.  (In
> fact, there have been one or two previous reports of build failures
> caused by NFS problems.)

OK, so even if he disabled the monitor file writing, he might have trouble.

>>You can probably work around this by setting DISTCC_DIR to some
>>directory on a local hard drive that you have write permission to.
> 
> 
> That might be a good idea.  tmpfs (or whatever it's called on Solaris)
> might work too.
> ...
> Let's work out what is really wrong.

OK, the report was

> However, when I have multiple builds going at the same time, using the same set of servers, I get one of the following three messages.
> 
> distccmon-text[10782] (dcc_close) ERROR: failed to close fd4: Stale NFS file handle
> or
> distccmon-text[960] (dcc_mon_read_state) Warning: wrong magic number: /home/ahasty/.distcc/state/binstate_12563

Perhaps he's running distccmon on a different machine
than the distcc client, and accessing ~/.distcc via nfs?
http://groups.google.com/groups?selm=netappCJyvKo.MrI%40netcom.com
suggests that readers should just assume files which return ESTALE
have been deleted.  That means dcc_close should ignore ESTALE.
No idea about the dcc_mon_read_state problem, though.
- Dan





More information about the distcc mailing list