Well, "more" accurate, yes, but not correct ..
> struct rlimit *rlim;
> if (getrlimit(RLIMIT_NOFILE, rlim)) { /* error */ }
> fd = rlim->rlim_cur;
> while (fd >=0 ) (void)close(fd--);
As you mention below, the limit can be reduced after a file has been opened,
meaning that fd's could be missed.
> Hmmm. Should calling setrlimit(RLIMIT_NOFILE, (struct rlimit *)NULL)
> close all open files? It of course doesn't, but should it?
As I understand it, only the kernel actually knowns the upper bound,
and without using a HACK such as listing /proc/self/fd/, it would be
necessary for the kernel to do the closing -- but I suspect that such
a change is likely to breaks certain programmes ...
Hmmm -- reading the man page in pedantic mode allows a different
interpretation ....
It suggests to me that by using dup2, it should be possible to get a very
high valued fd (much greater than the value of RLIMIT_NOFILE, and that
setting RLIMIT_NOFILE to zero *should* close all files :-)) It says:
RLIMIT_NOFILE /* max number of open files */
i.e. not (take off one as thge first fd is numbered zero) "the highest value
of fd that can be opened" [ which is how I have always interpreted it ]
but the *MAX NUMBER* of files (no mention of the fd values) that *CAN BE*
open (rather than that open / dup / dup2 can return) -- snigger !
-
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/