Question

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 exec?

Answer 1

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 /dev/null).