On the close-on-exec mechanism between Linux processes

Reprint please indicate the source: The Curtain Roll westerly column (Http://blog.csdn.net/ljxfblog)

A few days ago wrote a blog about the port occupancy of the view and resolution.

Solutions to view and occupy Linux system ports

Most of these problems can be solved, at the end of the article, a special case is mentioned, that is, the port occupancy in the parent-child process. After the parent process listens on a port, fork out a child process, then kill the parent process, and then restart the parent process, this time prompt port occupation, with Netstat view, the child process consumes the parent process listens to the port.

The principle is actually very simple, when the sub-process is fork out, using the copy-on-write (Cow,copy-on-write) method to obtain the parent process of the data space, heap and stack copies, which also includes the file descriptor. Just when fork succeeds, the same file descriptor in the parent-child process points to the same item in the System File table (which also means that they share the same file offset). This, of course, also contains the socket created by the parent process.

Then, in general, we call exec to execute another program, which replaces the body, data, heap, and stack of the child process with a completely new program. The variable that saves the file descriptor does not exist at this point, and we cannot close the useless file descriptor. So normally we'll fork the sub-process and execute close directly in the sub-process to turn off the useless file descriptor before executing exec.

But in a complex system, sometimes we fork the sub-process without knowing how many file descriptors are open, including the socket handle, which is really difficult to clean up at this point. We expect to be able to specify when a file handle is opened before the fork process: "This handle is closed when I execute EXEC after I fork the child process." In fact, there is such a way: the so-called close-on-exec.

back to our application scenario, as long as we create a socket with sock_cloexec Flag, we will be able to achieve the desired effect, when executing exec in the fork sub-process, the socket created by the parent process is cleaned out.

#ifdef Win32socket SS =:: Socket (pf_inet, sock_stream, 0); #elseSOCKET SS =:: Socket (pf_inet, Sock_stream | Sock_cloexec, 0); #endif

of course, other file descriptors have similar features, such as files that can be opened with the O_cloexec logo (Linux 2.6.23 only start to support this tag ), to achieve the same effect as above. Or you can use the FCNTL function of the system to set the Fd_cloexec.

Scenario Aint fd = open ("Foo.txt", o_rdonly); int flags = FCNTL (FD, F_GETFD); flags |= fd_cloexec;fcntl (FD, F_SETFD, flags);//Plan B , Linux 2.6.23 support int fd = open ("Foo.txt", O_rdonly | O_CLOEXEC);

Well, now we can finally solve the problem of end share population with this annoying question.

On the close-on-exec mechanism between Linux processes