I had this problem with a software I maintain. To fix it, I marked all the file descriptors "do-not-inherit", and then when the child was completed I caught SIGCHLD, compared the PID that had just died to the expected value, and then expressed the completion across all the SSL and non-SSL filedescriptors.
The symptom was that after fork() to save a copy of the current database (this was for a MUD server), the child would write to the sockets. The problem with this was that all the sockets were continuing in the parent process, so it appeared to be a replay attack, and the SSL protocol killed all of them. The simple fix is to ensure that only one process writes to the file descriptors, and that any communication that must be done be done via signals, shmem, or pipes. -Kyle H On 5/18/06, Marek Marcola <[EMAIL PROTECTED]> wrote:
Hello, > in this server i fork to use a independent exec. directly after the > exec in the child i call exit(0), exec() call returns only on error, if not, exec() terminates current process and load from executable into current process space new program. So if exec() is successful, there is no such thing like "exit(0)". > but then the SSL connection which is an exact copy of the parent gets > also deinitialized. Maybe there is some logic error ? To read from "ssl" file descriptors you need more than only system file descriptor. Best regards, -- Marek Marcola <[EMAIL PROTECTED]> ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
