[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

> 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