2019-11-14
| ||
01:11 | • Ticket [657abb4cd1] TLS Socket Closed in Child Process status still Open with 3 other changes artifact: 183ca4dc02 user: rkeene | |
2018-03-21
| ||
17:49 | • Ticket [657abb4cd1]: 5 changes artifact: 35f8675f69 user: anonymous | |
16:23 | • New ticket [657abb4cd1]. artifact: 01f98a177b user: anonymous | |
Ticket Hash: | 657abb4cd1f8f1032731ee0366c7cc643af778e7 | |||
Title: | TLS Socket Closed in Child Process | |||
Status: | Open | Type: | Feature Request | |
Severity: | Important | Priority: | Immediate | |
Subsystem: | Resolution: | Open | ||
Last Modified: | 2019-11-14 01:11:32 | |||
Version Found In: | 1.7.16 | |||
User Comments: | ||||
anonymous added on 2018-03-21 16:23:14:
If a parent process opens a TLS socket prior to forking, and its child process closes it, this has the unfortunate side-effect of terminating the parent's connection. With a non-TLS socket this does not happen, i.e., closing the parent's socket in the child has no effect on the parent.
anonymous added on 2018-03-21 17:49:16: In tls.c, Tls_Clean, if I comment out the BIO_free_all call, this problem goes away. However, will this cause a memory leak? Is there some better way you can think of that I can handle this situation? I would ideally like the option of closing the socket and freeing all OpenSSL structures but not sending a close notify. rkeene added on 2019-11-14 01:11:32: Probably the best solution is to enable "fast-path" during compilation, which lets OpenSSL handle that part of the process for TCP sockets. This will eventually be made the default, it seems to be much better. |