Le 22 mars 2013 à 19:16, Wietse Venema a écrit :
> [...]
>
> Hence my suggestion that Postfix use the kern.maxfilesperproc
> value, as in a separate response (with code).
Hello Wietse,
Intuitively, I came to that idea too.
But because all those ambiguities, and before I (perhaps) get an explanation
from Apple wrt their man page, I wanted to do a quick check.
So, I wrote another quick and dirty piece of code (I know, I can't refrain):
#include <sys/resource.h>
#include <limits.h>
#include <stdio.h>
#include <sys/errno.h>
int main(int argc, char **argv)
{
int i;
struct rlimit rl;
if (getrlimit(RLIMIT_NOFILE, &rl) < 0)
{
printf("getrlimit failed with rc=%i\n", errno);
return -1;
}
for (i = OPEN_MAX - 100; i < INT_MAX ; i++)
{
rl.rlim_cur = i;
if (setrlimit(RLIMIT_NOFILE, &rl) < 0)
{
printf("setrlimit failed with i=%i and
rc=%i\n", i, errno);
return -1;
}
}
printf("Ended with i=%i\n", i);
return 0;
}
and got those results:
$ sysctl kern.maxfilesperproc
kern.maxfilesperproc: 10240
$ ./setrlimit
setrlimit failed with i=10241 and rc=22
$ sudo sysctl -w kern.maxfilesperproc=12000
kern.maxfilesperproc: 10240 -> 12000
$ ./setrlimit
setrlimit failed with i=12001 and rc=22
$ sudo sysctl -w kern.maxfilesperproc=10240
kern.maxfilesperproc: 12000 -> 10240
$ ./setrlimit
setrlimit failed with i=10241 and rc=22
So, allowable values for rlim_cur indeed seem to be bounded by the value of
kern.maxfilesperproc; this appears quite logical, should one want to have such
bounds defined for the operation of setrlimit().
I guess the code of open_limit() may thus (more or less) safely be arranged
around the value of kern.maxfilesperproc.
And I now have a good reason to submit a bug report: the man page is wrong. ;-)
Axel
