Axel Luttgens:
> 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.
Apple does not own the getrlimit() API. It is part of a standard.
I sent the URLs in a different reply. If Apple changes their
implementation they they drop out of the standard.
To avoid confusion I'll use RLIM_INFINITY instead of INT_MAX but
we already know that it isn't going to make a difference for recent
MacOS versions.
What is the value of rlim_cur BEFORE Postfix changes it?
[OPEN_MAX=10240]
> This seems to be the value returned by "sysctl kern.maxfilesperproc":
> $ sysctl kern.maxfilesperproc
> kern.maxfilesperproc: 10240
That is the default limit. kern.maxfilesperproc can be changed.
The OPEN_MAX=10240 constant is safe for the SMALLEST possible
configuration. Postfix should not use that.
If the system administrator configures a larger value, then Postfix
should not limit itself to the default limit.
[sysconf(_SC_OPEN_MAX)]
If sysconf(_SC_OPEN_MAX) returns the same 256 as "getconf OPEN_MAX",
then that isn't going to be useful.
What does the following program print?
-------
#include <sys/types.h>
#include <sys/sysctl.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#define MAX_FILES_PER_PROC "kern.maxfilesperproc"
#define perrorexit(text) do { perror(text); exit(1); } while (0)
int main(int argc, char **argv)
{
int limit;
int len = sizeof(limit);
if (sysctlbyname(MAX_FILES_PER_PROC, &limit, &len,
(void *) 0, (size_t) 0) < 0)
perrorexit("sysctlbyname MAX_FILES_PER_PROC");
printf("%d\n", limit);
return (0);
}
-------
This will likely be the same as rlim_cur BEFORE Postfix changes it.
Wietse
