Carlo Marcelo Arenas Belon wrote:
> On Wed, Dec 02, 2009 at 10:36:02AM +0000, Daniel Pocock wrote:
>   
>> Carlo Marcelo Arenas Belon wrote:
>>     
>>> but that of course requires a patched version of apr (including
>>> bootstrapping) and is probably not an option, unless we go back
>>> to the dark ages of including all dependencies statically.
>>>   
>>>       
>> Maybe we can fix apr too
>>     
>
> Changing APR to use poll instead of kqueue is a way to fix it, but then
> to be able to use that fix, we will need to go back to have our own
> apr tree.
>
>   
>> I found a description of the same issue in a Google search on the subject:
>>
>> http://www.google.com/search?q=kqueue+fork+process+"bad+file+descriptor";
>> http://www.mail-archive.com/freebsd-hack...@freebsd.org/msg69516.html
>>
>> Can you try re-enabling kqueue and patching apr to use rfork()?
>>     
>
> Doesn't work, and fails now on sending of the metrics, because of course
> this time the parent process close that socket and the child can use it
> after that.
>
> The only viable solution I see is to delay the creation of all the sockets
> until daemonized as it was being done originally.
>   
The problem with that is that if another process is already listening on 
one of the ports wanted by gmond, then the listener set up will fail, 
but if the problem is only detected after daemonizing, then the caller 
doesn't know about the failure.

> If you really need to avoid having the parent report back on issues on that
> then you are going to keep the parent around and send the status back from
> the child until getting into the main loop through a unix socket or similar
> instead as you suggested originally was another option.
>   
That is not as easy to implement in apr as the apr_proc_detach() call.  
apr_proc_fork() is described as the only call in apr that is not 
portable.  apr_proc_create() could be used to invoke another gmond 
process, but I'm not sure that apr guarantees to preserve the file 
descriptors and memory allocations across that call.

Maybe the problem has something to do with the way detach recycles 
stdin/stdout/stderr?  As a quick test, could you try modifying gmond.c 
so that it calls fork() directly rather than calling apr_proc_detach()?



------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Ganglia-developers mailing list
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers

Reply via email to