https://bz.apache.org/bugzilla/show_bug.cgi?id=60487
--- Comment #3 from Jeff Wheelhouse <apa...@wheelhouse.org> --- "Did you take some explicit efforts to get a SIGHUP/WINCH sent during the load of the module?" No, unfortunately, it rears its ugly head all on its own. "I am wondering if there is something else more likely to delay the startup in practice, perhaps in Jacob's env?" There's no overlap between Jacob P and I, so I can't speak for him, but our environments definitely don't overlap. (I.e. there is no cPanel in my environment.) "I do think it's more likely you have back-to-back graceful signals and just ignoring the second is better. Maybe a good sanity check would be to look for mpm_state == AP_MPMQ_STARTING when retained == NULL and no-op'ing it altogether. An even safer option might be to only handle the graceful flavors w/ the new block, to avoid the chance a hard stop or hard restart is ignored if we're missing something?" These are good points. If I understand this correctly, basically ap_start_restart() is getting called at the wrong time. It expects to be called after "retained" is initialized, but it's getting called before that. That happens because the second restart happens before the first restart has finished initializing it. In other words, ap_start_restart() is getting called when the server hasn't started. So the patch I provided might really be addressing the effect, not the cause. It seems like a "correct" fix would cause ap_start_restart() not to be called when the server hasn't been started, either by deferring the 2nd restart until the first one is done or by ignoring it completely. So, the types of safer/sanity checks you're talking about... would they possibly be best-positioned higher up in the code? If so, would that be in the core, or is there something specific to mpm_event that isn't re-restarting properly? -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
