[ https://issues.apache.org/jira/browse/MESOS-1432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14011886#comment-14011886 ]
Till Toenshoff commented on MESOS-1432: --------------------------------------- Some pretty helpful debug code on the general subject of FD setup and possible leakage due to missing cloexec's: {noformat} void showFDInfo(int fd) { using std::cerr; using std::endl; char buf[256]; int fd_flags = fcntl(fd, F_GETFD); if (fd_flags == -1) return; int fl_flags = fcntl(fd, F_GETFL); if (fl_flags == -1) return; char path[256]; sprintf(path, "/proc/self/fd/%d", fd); memset(&buf[0], 0, 256); ssize_t s = readlink( path, &buf[0], 256 ); if (s == -1) { cerr << " (" << path << "): " << "not available" << endl; return; } cerr << fd << " (" << buf << "): "; if (fd_flags & FD_CLOEXEC) cerr << "cloexec "; // file status if (fl_flags & O_APPEND ) cerr << "append "; if (fl_flags & O_NONBLOCK) cerr << "nonblock "; // acc mode if (fl_flags & O_RDONLY ) cerr << "read-only "; if (fl_flags & O_RDWR ) cerr << "read-write "; if (fl_flags & O_WRONLY ) cerr << "write-only "; if (fl_flags & O_DSYNC ) cerr << "dsync "; if (fl_flags & O_RSYNC ) cerr << "rsync "; if (fl_flags & O_SYNC ) cerr << "sync "; struct flock fl; fl.l_type = F_WRLCK; fl.l_whence = 0; fl.l_start = 0; fl.l_len = 0; fcntl( fd, F_GETLK, &fl ); if (fl.l_type != F_UNLCK) { if (fl.l_type == F_WRLCK) cerr << "write-locked"; else cerr << "read-locked"; cerr << "(pid:" << fl.l_pid << ") "; } cerr << endl; } void showFDInfo() { int numHandles = getdtablesize(); for (int i = 0; i < numHandles; i++) { int fd_flags = fcntl(i, F_GETFD); if (fd_flags == -1) continue; showFDInfo(i); } } {noformat} Works on linux only and is taken from http://oroboro.com/file-handle-leaks-server/ > Atomically set close-on-exec where possible. > -------------------------------------------- > > Key: MESOS-1432 > URL: https://issues.apache.org/jira/browse/MESOS-1432 > Project: Mesos > Issue Type: Bug > Reporter: Benjamin Mahler > > In our multi-threaded code, there is a race between opening a file descriptor > and setting close-on-exec on it: if a fork occurs between these operations > then we have leaked the file descriptor to the child process. > Some required reading: > http://udrepper.livejournal.com/20407.html > We should do an audit of all of our code to ensure we're doing avoiding this > race where possible. -- This message was sent by Atlassian JIRA (v6.2#6252)