[distcc] Problem with zeroconf daemonization

Benjamin R. Haskell distcc at benizi.com
Mon Jan 18 08:31:29 MST 2010


[self-reply]

On Mon, 18 Jan 2010, Benjamin R. Haskell wrote:

> On Mon, 18 Jan 2010, Lennart Poettering wrote:
> 
> > Uh, hardcoding the 1024 is not a good idea. And always looping up to 
> > RLIMIT_NOFILE or _SC_OPEN_MAX is actually kinda slow. Looping 
> > through /proc/self/fd/ should be the fastest way to close all those 
> > fds.
> 
> Yeah, sorry all, should've added <sarcasm> tags w/ actually-using 
> 1024.  That said, it's not clear what the best alternative is.

Pretty good discussion of alternatives+caveats at:

http://stackoverflow.com/questions/899038/getting-the-highest-allocated-file-descriptor#answer-918469

> [...]
> 
> How universal is /proc/self/fd/?
>

See part of above link -- seems AIX is the main holdout, plus /dev/fd/ 
on FreeBSD and derivatives [Darwin is FreeBSD-derived, right?].


> > Might be an idea to simply copy this function:
> > 
> > http://git.0pointer.de/?p=libdaemon.git;a=blob;f=libdaemon/dfork.c;h=70fce862894ba16d66127d10547799aaa045fad4;hb=refs/heads/master#l485
> 
> Sure, modulo portability of /proc/self/fd/.  Or is the Avahi stuff the 
> limiting factor in portability anyway?  (no slight intended -- just 
> curious -- it would surprise me if it were)

Seems like the right path, given the '/proc/[pid]/fd/' and '/dev/fd/' 
caveats mentioned at the link.


> Either way, though, there seems to be agreement that this is a 'distcc' 
> problem and not a 'paludis' problem?

[still interested in the consensus here]

Best,
Ben


More information about the distcc mailing list