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. Cheers, Stefan > Am 26.09.2019 um 13:10 schrieb Yann Ylavic <ylavic....@gmail.com>: > > On Thu, Sep 26, 2019 at 8:20 AM Pluem, Ruediger, Vodafone Group > <ruediger.pl...@vodafone.com> wrote: >> >>> -----Ursprüngliche Nachricht----- >>> Von: Yann Ylavic <ylavic....@gmail.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) :/ > > Regards, > Yann. > <some_pchild_to_pconf-v3.diff>
