On Mon, Dec 28, 2009 at 11:05:36PM +0000, Daniel Pocock wrote: > Carlo Marcelo Arenas Belon wrote: >> On Fri, Dec 18, 2009 at 04:18:16PM +0000, Daniel Pocock wrote: >> >>> Carlo Marcelo Arenas Belon wrote: >>> >>>> On Sun, Dec 13, 2009 at 10:49:00AM +0000, Daniel Pocock wrote: >>>> >>>>> I could accept Brooks' solution, because it means gmond would >>>>> only fail for something like out-of-memory, while any >>>>> configuration failure, port in use, etc would cause it to fail >>>>> before detaching. >>>>> >>>> If gmond still fails silently in some cases, you have not accomplished the >>>> objective that you were trying to obtain with r2025 anyway. >>>> >>> I agree - it doesn't completely meet my goal, but it does at least >>> result in an error code for most types of bad configuration (or port >>> in use) >> >> that part is OK, but you still have the added sideeffects of r2025 which >> would affect gmond in other interesting ways : >> >> * the metric (and module) initialization is now done by the parent and >> expected to be inherited by the child, this means for example that >> the >> parent will send (and receive) metric information (even before forking) >> * the suid is done by the parent and therefore the child isn't privileged >> (while the metric initialization was done as root), this would at least >> prevent anyone to bind gmond to privileged ports but also could result >> in complicated permission issues by metric collection scripts. >> >> as I said before I think the apr_poll issue with BSD should be taken as >> a warning of how the changes we were planning to do could have unintended >> sideeffects, and since moving the daemonization was only one way to solve >> the original problem, makes more sense to instead revert this change and >> evaluate alternatives. >> > It is this line of argument, rather than the concerns about APR, that > makes me think reverting the change completely might be the way to go > for now, although the reason for the change is still a legitimate issue > and can be tracked in bugzilla.
agree, and I have to admit I am surprised this (which was my main argument) somehow wasn't made clear until now. indeed, the proposed alternative implementation of a fix was published just because I agree that this issue is legitimate a bug (even if there might not be a bugzilla for it) which needed to be corrected anyway. > Maybe this type of disruptive change will have to come in 3.2, there we > can look at the various phases of initialisation more closely, prompt > people to review their modules, etc. I was looking forward for 3.2 being the windows native version and therefore if the problem with the initialization is solved in a windows incompatible way then we are going to be left with no other option than to do this disruptive change there anyway. Carlo ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
