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

Ciaran McCreesh ciaran.mccreesh at googlemail.com
Wed Feb 24 19:39:59 UTC 2010

On Mon, 25 Jan 2010 03:01:22 -0500 (EST)
"Benjamin R. Haskell" <paludis at benizi.com> wrote:
> > Ebuilds aren't allowed to spawn processes that last longer than the 
> > ebuild itself. The same applies to anything you sneakily make
> > ebuilds do.
> I'm not sure what you mean by "aren't allowed to"...  "are prohibited
> by official policy"?  So, an ebuild calling distcc -j would be 
> out-of-bounds?   Or do you mean that the wait is supposed to be
> enforced programmatically?
> The 'distcc -j' isn't called in an ebuild -- I use it in my own 
> /etc/paludis/bashrc to set up my $MAKEARGS.

It's forbidden by policy, and there's no particular reason for it to be
expected to work. By setting up distcc the way you have, you're
effectively tricking the ebuild into doing something illegal, which
won't work.

A double fork for anything that's supposed to outlast the ebuild
process is probably the sanest answer.

> > 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.
> ...the daemon spawned by distcc -j appears to not double-fork, but it 
> does setsid().  And, the attached program triggers the same behavior 
> w.r.t. outputwrapper, unless called with the with-closed-fds wrapper 
> from my initial email.  (double-forked-simple.c just double forks, 
> closes fd's 0-2, setsid()s, and sleeps for 20 seconds.)  But maybe
> I'm missing something the 'distcc' code misses, too.

Sessions are something else. They're not related to reparenting.

Ciaran McCreesh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.exherbo.org/pipermail/paludis-user/attachments/20100224/51b58693/attachment.asc>

More information about the paludis-user mailing list