Le 21 mars 2013 à 18:26, Wietse Venema a écrit :
> Axel Luttgens:
>> Calling setrlimit() with 2147483647 for rl.rlim_cur fails, but
>> succeeds with 10240. This is consistent with the very last sentence
>> of the man page's compatibility section.
>
> Apple does not own the getrlimit() API. It is part of a standard.
> I sent the URLs in a different reply. If Apple changes their
> implementation they they drop out of the standard.
Damn... all of this started with such a seemingly innocuous detail... :-(
Anyway, please refer to my other post as far as a possible bug report to Apple
is concerned.
> To avoid confusion I'll use RLIM_INFINITY instead of INT_MAX but
> we already know that it isn't going to make a difference for recent
> MacOS versions.
Yes, probably...
> What is the value of rlim_cur BEFORE Postfix changes it?
Unless I made a mistake, it is 256.
From my previous post:
Just after the "if (limit > 0)" test, the values are:
limit: 2147483647, rl.rlim_cur: 256, rl.rlim_max:
9223372036854775807
> [OPEN_MAX=10240]
>
>> This seems to be the value returned by "sysctl kern.maxfilesperproc":
>> $ sysctl kern.maxfilesperproc
>> kern.maxfilesperproc: 10240
>
> That is the default limit. kern.maxfilesperproc can be changed.
>
> The OPEN_MAX=10240 constant is safe for the SMALLEST possible
> configuration. Postfix should not use that.
>
> If the system administrator configures a larger value, then Postfix
> should not limit itself to the default limit.
>
> [sysconf(_SC_OPEN_MAX)]
>
> If sysconf(_SC_OPEN_MAX) returns the same 256 as "getconf OPEN_MAX",
> then that isn't going to be useful.
>
> What does the following program print?
>
> -------
> [...]
> -------
I had to change "int len = ..." into "size_t len = ..." so as to avoid a
warning.
The ouput is: 10240.
Thanks again,
Axel
