Oct 2, 2019, 5:40 AM
Post #12 of 12
Coming back to this, I ran the v3 patch several times in the mod_md test suite and had no crashes reported.
Now, about the side effects you mentioned, I cannot judge how severe that is and if it is worth it. mod_md itself does not mind if the child process is exiting early. It's just the crash reported about OpenSSL that is annoying.
I think we should have a not-crashing server, but there is no urgency for a quick fix.
> Am 26.09.2019 um 13:10 schrieb Yann Ylavic <email@example.com>:
> On Thu, Sep 26, 2019 at 8:20 AM Pluem, Ruediger, Vodafone Group
> <firstname.lastname@example.org> wrote:
>>> -----Ursprüngliche Nachricht-----
>>> Von: Yann Ylavic <email@example.com>
>>> Likewise, I think the MPMs themselves shouldn't use pchild for their
>>> internal allocations possibly still in use at exit().
>>> So v2 (attached) may be the thing..
>> Hm, haven't checked, but aren't there any cleanups that should run and
>> currently run before exit that will not run any longer when we tie
>> stuff to pconf instead of pchild?
>> I guess pure allocations are not a problem, since the process dies,
>> but I would be a little worried about other OS resources like
>> shared memory or locks not being cleaned up properly.
> I think you are right, proc mutexes at least need to cleanup properly
> on child exit.
> I updated the patch (attached) to keep them on pchild.
>> Regarding the watchdog threads I guess we could handle this
>> like Stefan suggested by handling it similar to still running connections.
>> Give them a grace period and kill them afterwards during regular shutdown.
>> For an immediate shutdown kill them off directly.
> Killing threads is going to be hard to achieve, all the more so in a
> portable way. There is no apr_thread_kill() for instance,
> pthread_kill() is not suitable, I know of tgkill() on linux...
> But we shouldn't take that road IMHO, and regarding the state of
> shared/proc resources potentially used by these threads it looks like
> a can of worms..
> Asking for watchdog callbacks (including third-parties') to
> [un]gracefully stop is not something in the current "contract"
> unfortunately, we are quite weaponless here I'm afraid.
> So I can only think of _exit() like in attached v3, although in
> addition to not run atexit() handlers _exit() also potentially does
> not flush stdios, but all fds are closed so pending outputs should
> still finish (for whatever that means in linux/BSD docs..).
> This is still going to be racy with anything initialized on pchild
> though, like mod_ssl caches mutexes (session, stapling) :/