Axel Luttgens:
> Hello,
>
> (Not sure whether the postfix-devel list is the right place for
> such matters; please let me know if another place, for example the
> postfix-users list, would be more suitable)
The place is OK.
> Starting with Mac OS X 10.5, the man page for setrlimit(2) comes
> with following compatibility section:
>
> setrlimit() now returns with errno set to EINVAL in places that
> historically succeeded. It no longer accepts "rlim_cur = RLIM_INFINITY"
> for RLIM_NOFILE. Use "rlim_cur = min(OPEN_MAX, rlim_max)".
Postfix does not ask for RLIM_INFINITY file descriptors (if someone
modified Postfix, you should bug the guilty party instead).
How can this code:
if (limit > 0) {
if (limit > rl.rlim_max)
rl.rlim_cur = rl.rlim_max;
else
rl.rlim_cur = limit;
setrlimit(RLIMIT_NOFILE, &rl)
produce an error for any "limit" value > 0? Does rlim_max contain
a value that is not allowed for rlim_cur? That would warrant a MacOS
bugreport, as the rlim_max value came from the MacOS system itself,
not from Postfix.
Please print the rlim_max value and report it on the list.
This would need to be verified before I will make any code changes
for Postfix.
> +#ifdef MACOSX
> + if (limit > OPEN_MAX) limit = OPEN_MAX;
> +#endif
Assuming that the above problem is real, your solution would seriously
cripple Postfix. OPEN_MAX is a constant; it is a lower bound (a
measly 64 on FreeBSD which sits under much of MacOS).
Such a tiny number may be OK for simple apps but not for Postfix
which needs to be able to scale up with real hardware.
I think a better solution would be based on sysconf(_SC_OPEN_MAX)
which reflects the true system limit.
if (limit > 0) {
long sysconf_limit;
sysconf_limit = sysconf(_SC_OPEN_MAX);
if (sysconf_limit < 0)
return (-1);
if (limit > sysconf_limit)
limit = real_limit;
...
That way we have an authoritative estimate of what the system
can do for Postfix.
Wietse
