Restart a failed shared SSL daemon process automatically?

Using the description from the CASE.
jvfarmer (IBM)
Jan 18, 2022, 08:42
We have been working on diagnostic improvements to shared SSL, and have gotten some corruption detection in place, but we don't believe adding this code formally is the correct approach. For starters, recovering from the corruption opens up other issues. For example, lets say a hash bucket has a corrupted address, TPF detects that corruption, and cleans up the chain pointer. Lets say that corrupted chain contains the CTX for an INETD SSL server. Well, in this case, the INETD SSL server does not accept any new connections if that is the daemon process the CTX is associated with.

If the hash table corruption is occurring from other processing, outside of shared SSL, the diagnostic improvements won't help determine the cause of the corruption either. Or at least won't provide anything new of value than what we have today. After much discussion we have decided not to pursue the diagnostic improvement as we don't believe it will provide a lot of value. In addition, all of this chain pointer checking will likely negatively affect the performance of shared SSL.

Trying to detect this one type of corruption programmatically and recover from it is not the best approach here. Our thoughts are to enhance the OpenSSL shared SSL code base to restart failed daemon processes, rather than try to detect/recover the system heap corruption.

Would it be possible to open an RFE asking for support to restart a failed shared SSL daemon process automatically? This way if we encounter any memory depletion or any type of corruption that causes a dump, the shared SSL daemons will recover automatically?