Axel Luttgens:
[ Charset ISO-8859-1 unsupported, converting... ]
> Le 22 mars 2013 ? 20:46, Wietse Venema a ?crit :
>
> > Wietse Venema:
> >> Do you need code for testing the sysctl() stuff?
> >
> > To make the job easier, below is a patch to unmodified open_limit.c
> >
> > Wietse
> >
> > [...]
>
> Fine, thanks Wietse!
>
> I like that solution, since it doesn't change the code's behavior
> for other OSes (a behavior that seems to have been adequate for
> more than a decade).
>
> Still wondering whether Mac OS X is the only platform to set
> restrictions on the values passed to setrlimit().
It certainly makes sense for setrlimit() to forbid rlim_cur values
larger than the hard upper limit. That's what the hard limit is for.
The bug is that Mac OS X rlim_max equals RLIM_INFINITY, instead of
the true hard limit kern.maxfilesperproc, as it is on FreeBSD 8.2
and 9.0. If they could fix that then setrlimit() would not have
this misleading behavior where it claims the limit is unbounded but
it is not.
> BTW, I didn't immediately notice the long type for current_limit,
> and thus got immediate failures: getsysctlbyname() returned values
> such as 0x7FD500002800 -note the 0x00002800 half- and this proved
> even worse than INT_MAX... ;-)
Yeah. It's "int" on 32-bit and 64-bit FreeBSD, too. So now we have
fixed open_limit.c.
Wietse
