Axel Luttgens:
> The change described in my other post ("Mac OS X and setrlimit(2)")
> is required as well, since one will now call open_limit(INT_MAX)
> instead of open_limit(FD_SETSIZE).
We don't use quick-and-dirty patches. Have you tried my (proper) fix?
Wietse
Viktor Dukhovni:
> On Thu, Mar 21, 2013 at 03:38:35PM -0400, Wietse Venema wrote:
>
> > Axel Luttgens:
> > [default open file rlim_max = 9223372036854775807]
> >
> > Thanks for doing the experiments. On 64-bit systems the number
> > 9223372036854775807 equals RLIM_INFINITY.
>
> An interesting AP
Axel Luttgens:
> So, looks quite promising. :-)
> Are there other tests I could/should run in order to be fully reassured?
Does it work with postscreen? (turn off postscreen cache, turn on
"after 220 greeting" tests, then do the same tests as with smtpd).
Does it work with FIFOs for qmgr and pick
Since I needed to compile Postfix, I thought this could be the opportunity to
check the state of kqueue on Mac OS X at the same time: the most recent thread
I could find about those matters is the one that started with
http://www.mailinglistarchive.com/html/postfix-devel@postfix.org/2007-03/msg0
On Thu, Mar 21, 2013 at 03:38:35PM -0400, Wietse Venema wrote:
> Axel Luttgens:
> [default open file rlim_max = 9223372036854775807]
>
> Thanks for doing the experiments. On 64-bit systems the number
> 9223372036854775807 equals RLIM_INFINITY.
An interesting API choice, since file descriptors la
Le 21 mars 2013 à 18:26, Wietse Venema a écrit :
> 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 i
On Thu, Mar 21, 2013 at 01:26:24PM -0400, Wietse Venema wrote:
> What does the following program print?
>
> ---
> #include
> #include
> #include
> #include
> #include
>
> #define MAX_FILES_PER_PROC "kern.maxfilesperproc"
>
> #define perrorexit(text) do { perror(text); exit(1); } whil
Axel Luttgens:
[default open file rlim_max = 9223372036854775807]
Thanks for doing the experiments. On 64-bit systems the number
9223372036854775807 equals RLIM_INFINITY. This implies that
MacOS X does not enforce the open file limit.
This rlim_max value breaks a heuristic that Postfix uses to i
Le 21 mars 2013 à 15:02, Wietse Venema a écrit :
>> [...]
>
> 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
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.
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 ma
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.
>
>> Starti
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
> wit
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)
Starting with Mac OS X 10.5, the man page for setrlimit(2) comes with following
compatibility section:
14 matches
Mail list logo