2010/1/18 Benjamin R. Haskell <[email protected]>: > 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 _______________________________________________ paludis-user mailing list [email protected] http://lists.pioto.org/mailman/listinfo/paludis-user
