On Wed, Dec 02, 2009 at 11:17:26AM +0000, Daniel Pocock wrote: > Carlo Marcelo Arenas Belon wrote: >> On Wed, Dec 02, 2009 at 10:36:02AM +0000, Daniel Pocock wrote: >>> >>> 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.
but that is something that could be fixed at the caller level but just checking if the port is bound to something already before calling gmond. agree that is not elegant, but is better than the current situation where you can't start gmond at all. >> 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. frankly I don't like much all the abstractions that apr_* provides because makes simple things like this more complicated (specially because of the unintended sideeffects) but since apr_proc_detach is just calling fork and reopening the 3 std filehandles shouldn't be that difficult to work around. > 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. apr_proc_fork() is not called by apr_proc_detach() AFAIK, indeed I was surprised to see it even existed when noticed that apr_proc_detach calls fork() directly. > 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()? fork() doesn't work because the kqueue filehandle is not inherited; using rfork() instead doesn't either because all filehandles are closed by doing exit(0) in the parent and so fails in the same way that changing apr_proc_detach() does when changed to use rfork() instead. Carlo ------------------------------------------------------------------------------ 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
