Axel Luttgens:
> > If rlim_cur value is enforced, as it may well be, then my next bet
> > is to use the sysctl() result. A hard constant value would be
> > fundamentally incorrect.
>
> Indeed, it is enforced; for example, with rlim_cur set to 10:
>
> postfix/master[73696]: fatal: open /_ROOT/etc/postfix/master.cf:
> Too many open files
[diagnostics]
> And even propose a quick diagnostic, a bit ? la Dovecot with its
> "Warning: fd limit (ulimit -n) is lower than required under max.
> load (256 < 1000), because of ..." messages. It would then be the
> system administrator's responsibility to provide the right settings.
Postfix already logs this, only the threshold is different.
I don't think that sysadmins should suffer because Apple has 10240
in the per-process kernel limit and only 256 in the rlimit structure.
On FreeBSD, from which much of Apple code is derived, the sysctl()
value is the same as the rlimit value:
$ limits
...
openfiles 11095
...
$ sysctl kern.maxfilesperproc
kern.maxfilesperproc: 11095
Hence my suggestion that Postfix use the kern.maxfilesperproc
value, as in a separate response (with code).
Wietse
