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.
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. ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/ganglia-developers
