Darragh Bailey wrote: > Since then we are occassionally seeing a problem where if a > subprocess executed manages to hang, closing down the daemon > and restarting it will run into a problem with binding to the port.
> My suspicion is that when we create the socket connections to > listen on using the BIO functions that because we are not setting > the FD_CLOEXEC on the socket any executed subprocess also see's > this socket, so that when the close is issued, the socket doesn't > actually close down fully or enter the TIME_WAIT state until > there is a timeout. You should not issue a 'close' unless you want to close the socket descriptor. If you want to shutdown the network connection, you should call 'shutdown'. If you call 'close', you lose the chance to call 'shutdown'. Your problem is just as much that the daemon is not shutting down its network connections as it is that the subprocesses are holding references to them. Fixing either inner problem will fix your outer problem. Although, if the daemon crashes, it will have no opportunity to shutdown its connections. It is not, IMO, a generally good idea to rely on 'close' to implicitly shutdown a network connection. This capability is largely only provided for naive applications to automatically DTRT even if they don't know they're talking to a network connection. If you want to shutdown a network connection, you should do so explicitly. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
