Wietse Venema:
> 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)".
You might want to file a MacOS bug report. According to SUSV2 (Single
UNIX Specification, Version 2, from 1997)
Specifying RLIM_INFINITY as any resource limit value on a
successful call to setrlimit() inhibits enforcement of that
resource limit.
http://pubs.opengroup.org/onlinepubs/7908799/xsh/getrlimit.html
Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004 Edition:
Specifying RLIM_INFINITY as any resource limit value on a
successful call to setrlimit() shall inhibit enforcement of
that resource limit.
http://pubs.opengroup.org/onlinepubs/009696799/functions/getrlimit.html
Based on this I think that a conforming setrlimit() implementation
must accept RLIM_INFINITY as "any resource limit value". resource
limit value.
Wietse
> 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
>
