httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [Bug 60487] Core dumps in mpm_event during graceful restart
Date Thu, 16 Feb 2017 19:49:38 GMT

--- Comment #3 from Jeff Wheelhouse <> ---
"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

"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

You are receiving this mail because:
You are the assignee for the bug.
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message