> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of > Daniel-Constantin Mierla > Sent: Monday, April 01, 2019 03:41 > > 4) kamailio forks and each process is using its own SSL_CTX structure for > accepting or > connecting over tls -- each child process will also reconnect to backend, if > it needs it for > runtime
Unfortunately for your purposes, OpenSSL does not guarantee correct operation when called from the child side of a fork (prior to exec). See: https://wiki.openssl.org/index.php/Libcrypto_API#Fork_Safety That said, using OpenSSL in a non-exec'd child process is common enough that the wiki also has a page on reseeding the PRNG after a fork - no longer relevant with 1.1, with the PRNG rewrite, but it suggests that the issue was relatively common. Based on the evidence (which isn't much), it appears at least one of the locks (implemented as pthread mutexes on Linux) was locked when you forked. Since libcrypto and libssl aren't built with symbols, we can't guess which lock. I suggest you build OpenSSL for debugging so you can get some useful information at the point of failure, then try to trace it back to confirm what was locked after the fork (put a breakpoint on the child side of the fork, then inspect the mutex object at that point). Then you can try to figure out why it was locked when you forked. OpenSSL 1.1.1b doesn't seem to provide a way to reinitialize the mutexes programmatically after a fork. -- Michael Wojcik Distinguished Engineer, Micro Focus
