lkml.org 
[lkml]   [1999]   [May]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: FD_CLFORK or equivalent?
Date
From
> 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/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.083 / U:0.288 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site