I have the following situation (pseudocode):
function f: pid = fork() if pid == 0: exec to another long-running executable (no communication needed to that process) else: return "something"
f is exposed over a XmlRpc++ server. When the function is called over XML-RPC, the parent process prints "done closing socket" after the function returned "something". But the XML-RPC client hangs as long as the child process is still running. When I kill the child process, the XML-RPC client correctly finishes the RPC call.
It seems to me that I'm having a problem with
fork() copying socket descriptors to the child process (parent called
closesocket but child still owns a reference -> connection still established). How can I circumvent this?
EDIT: I read about
FD_CLOEXEC already, but can't I force all descriptors to be closed on
No, you can't force all file descriptors to be closed on exec. You will need to loop over all unwanted file descriptors in the child after the
fork() and close them. Unfortunately, there isn't an easy, portable, way to do that - the usual approach is to use
getrlimit() to get the current value of
RLIMIT_NOFILE and loop from 3 to that number, trying
close() on each candidate.
If you are happy to be Linux-only, you can read the
/proc/self/fd/ directory to determine the open file descriptors and close them (except 0, 1 and 2 - which should either be left alone or reopened to