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().
Perhaps not, should the man page at:
http://www.unix.com/man-page/all/2/setrlimit/
be trusted (see description of error EPERM).
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... ;-)
For our records, I reproduce hereafter the changes I have applied to
open_limit.c.
Axel
--- src/util/open_limit.c.original 1998-12-11 19:55:29.000000000 +0100
+++ src/util/open_limit.c 2013-03-23 15:18:25.000000000 +0100
@@ -34,6 +34,16 @@
#include <sys/resource.h>
#include <errno.h>
+/*
+ * XXX MacOSX rlim_cur is only 256, rlim_max is infinite, so we use the
+ * kern.maxfilesperproc value instead, because setrlimit(2) on that OS
+ * doesn't allow arbitrary values for setting rlim_cur.
+ */
+#ifdef MACOSX
+#include <sys/sysctl.h>
+#define MAX_FILES_PER_PROC "kern.maxfilesperproc"
+#endif
+
/* Application-specific. */
#include "iostuff.h"
@@ -63,6 +73,16 @@
if (getrlimit(RLIMIT_NOFILE, &rl) < 0)
return (-1);
if (limit > 0) {
+#ifdef MACOSX
+ int current_limit;
+ size_t len = sizeof(current_limit);
+
+ if (sysctlbyname(MAX_FILES_PER_PROC, ¤t_limit, &len,
+ (void *) 0, (size_t) 0) < 0)
+ return (-1);
+ if (limit > current_limit)
+ limit = current_limit;
+#endif
if (limit > rl.rlim_max)
rl.rlim_cur = rl.rlim_max;
else
