Re: Problem with zeroconf daemonization

On Mon, 18 Jan 2010, Lennart Poettering wrote:

> On Mon, 18.01.10 01:10, Benjamin R. Haskell ([email protected]) wrote:
> 
> > If so, it seems like a pretty easy fix (to just close more fd's than 
> > 0,  1, and 2).  I can commit the attached patch if 1024 doesn't seem 
> > too  magic-number-y (and I'm not spouting nonsense).
> 
> 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.

In some one-off thing I wrote I used:

#include <linux/limits.h>
for (fd = 0; fd < NR_OPEN; fd++) close(fd);

But, obviously that's Linux-specific.  And as Lennart points out, it can 
be slow. (didn't notice w/ what I used it for)


How universal is /proc/self/fd/?


> 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)


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

Best,
Ben
__
distcc mailing list            http://distcc.samba.org/
To unsubscribe or change options:
https://lists.samba.org/mailman/listinfo/distcc