Le 21 mars 2013 à 13:58, Wietse Venema a écrit : > 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).
Well... I started with the source code of Postfix 2.10.0 as downloaded from one of the official mirrors (ftp://ftp.easynet.be/postfix/index.html). I hope "they" didn't made a mess of it. ;-) > 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. More precisely, the problem seems to be related to allowable values for rlim_cur: INT_MAX doesn't seem to belong to that set. But agreed: the man page might deserve some rewriting. > Please print the rlim_max value and report it on the list. Just after the "if (limit > 0)" test, the values are: limit: 2147483647, rl.rlim_cur: 256, rl.rlim_max: 9223372036854775807 Without the "fix", those values are before the call to setrlimit(): limit: 2147483647, rl.rlim_cur: 2147483647, rl.rlim_max: 9223372036854775807 > 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 > while they are, with the "fix": limit: 10240, rl.rlim_cur: 10240, rl.rlim_max: 9223372036854775807 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. > 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. In the case of Mac OS X, sys/syslimits.h shows: #define OPEN_MAX 10240 /* max open files per process - todo, make a config option? */ This seems to be the value returned by "sysctl kern.maxfilesperproc": $ sysctl kern.maxfilesperproc kern.maxfilesperproc: 10240 I've just checked on a 10.3.9 box: this was already the case. > I think a better solution would be based on sysconf(_SC_OPEN_MAX) > which reflects the true system limit. Here, sysconf(_SC_OPEN_MAX) returns 256, which is consistent with: $ getconf OPEN_MAX 256 $ ulimit -n 256 and which also appears to be the default value returned for rlim_cur by getrlimit(). Please do not hesitate, should you need additional info. And thanks for your feedback, Axel
