Messages in this thread | | | Subject | Re: FD_CLFORK or equivalent? | Date | Thu, 06 May 1999 11:27:50 +0200 | From | Olaf Titz <> |
| |
> Richard> fd = open("/", O_RDONLY); > Richard> while (fd >= 0) (void)close(fd--);
Wrong. After close(n) the next open() will return at most n. There is enough code which relies on that behaviour (think of n==0 and opening the standard fds).
> struct rlimit *rlim; > if (getrlimit(RLIMIT_NOFILE, rlim)) { /* error */ } > fd = rlim->rlim_cur; > while (fd >=0 ) (void)close(fd--);
This is how getdtablesize() in glibc works, and it is broken for at least one reason: You want to make that rlim_max, because a process could have opened (or inherited!) a fd and subsequently lowered rlim_cur. But by extension of that argument, even this is unreliable. Closing _really_ all file descriptors under any circumstances would require access to the maximum fd which _ever_ was allowed on the running system. This info is not available, not even via sysctl. (It is in the kernel headers, but you want to be able to read it at run time, or your program would be kernel version dependent.)
But you can find the highest numbered open fd of the current process with listing /proc/self/fd. Obviously this is a candidate for a new routine in libc.
> Hmmm. Should calling setrlimit(RLIMIT_NOFILE, (struct rlimit *)NULL) > close all open files? It of course doesn't, but should it?
I don't think so. (Why NULL? If this sets the limit to zero it sets the hard limit too, and subsequently you won't be able to do much.) The limit seems to apply only to files opened subsequently.
Olaf
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |