Le 21 mars 2013 à 20:38, Wietse Venema a écrit :
> Axel Luttgens:
> [default open file rlim_max = 9223372036854775807]
>
> Thanks for doing the experiments. On 64-bit systems the number
> 9223372036854775807 equals RLIM_INFINITY. This implies that
> MacOS X does not enforce the open file limit.
>
> This rlim_max value breaks a heuristic that Postfix uses to increase
> the number of open files to the hard limit (Postfix expects that
> rlim_max will always be smaller than INT_MAX, and tries to set the
> current (rlim_cur) limit to no more than that value).
>
> Below is a patch that fixes the heuristic. When the system reports
> an RLIM_INFINITY hard limit for the number of open files, there is
> no need for Postfix to update the open file limit, because it is
> not enforced.
Hello Wietse,
Thanks for having provided the rationale behind the checks.
> Please give this a try, and report if this cures the problem.
So, to be sure I am in sync, this is the change I've introduced in open_limit.c:
--- src/util/open_limit.c.original 1998-12-11 19:55:29.000000000
+0100
+++ src/util/open_limit.c 2013-03-22 08:56:07.000000000 +0100
@@ -62,7 +62,8 @@
#ifdef RLIMIT_NOFILE
if (getrlimit(RLIMIT_NOFILE, &rl) < 0)
return (-1);
- if (limit > 0) {
+ /* Don't update the limit when it is not enforced. */
+ if (limit > 0 && rl.rlim_max != RLIM_INFINITY) {
if (limit > rl.rlim_max)
rl.rlim_cur = rl.rlim_max;
else
This indeed allows a successful launch of master, qmgr...
But this leaves us with a rather low soft limit (rlim_cur) of 256 descriptors
by default in the case of Mac OS X. Doesn't this come with potential problems?
And, kind of thought experiment: what if Apple later decides to set a bound
hard limit by default, instead of an unbound one?
> BTW looks like this file hasn't changed in a long time.
Yes, 1998! Quite impressive... ;-)
Axel
