[paludis-user] Workaround for problem with distcc + outputwrapper

Ciaran McCreesh ciaran.mccreesh at googlemail.com
Fri Jan 22 10:47:53 UTC 2010


2010/1/18 Benjamin R. Haskell <paludis at benizi.com>:
> The problem is that 'distcc -j' with zeroconf fires off a daemon (See
> http://lists.samba.org/archive/distcc/2004q4/002774.html for the
> justification -- basically: the startup cost for collecting mDNS
> information is worth avoiding in a build that calls distcc many times.)

Ebuilds aren't allowed to spawn processes that last longer than the
ebuild itself. The same applies to anything you sneakily make ebuilds
do.

> So, from the way 'outputwrapper' works, the problem is that
> 'outputwrapper's fd's aren't in the set that get closed by 'distcc'
> before daemonizing.  And 'distcc' would thus sleep for 20 seconds every
> time 'bashrc' got sourced, unless I happened to have run 'distcc'
> outside of paludis (so that the daemon was already running outside of
> outputwrapper).

Are you really really sure that that's the issue? I strongly suspect
that it's not in the least bit FD related, since we've been passing a
'spare' FD around (to avoid having to use sockets, which have
permissions ick) for ages.

I suspect the real problem is that the daemon doesn't fork itself
twice, to make itself owned by init rather than the spawning process.

> I'm going to suggest on the distcc list that the daemonization process
> closes a larger set of fd's.  (There is also a similar problem with some
> leaked fd's in the LVM2 utilities -- I've not corresponded w/ that
> community ever, but I'll try to find them, too.)  But, I just wanted to
> share the workaround if anyone else was having trouble (seems unlikely).

Closing a larger set of FDs also really isn't the solution... If it
really is FD related, using dup2 rather than dup might be what's
called for.

-- 
Ciaran McCreesh



More information about the paludis-user mailing list