[paludis-user] Workaround for problem with distcc + outputwrapper
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
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
More information about the paludis-user