Date: Mon, 20 Feb 1995 01:56:03 -0500 (EST) From: Wankle Rotary Engine <wpaul@skynet.ctr.columbia.edu> To: freebsd-hackers@FreeBSD.org Subject: getrlimit()/setrlimit() strangeness Message-ID: <199502200656.BAA02173@skynet.ctr.columbia.edu>
next in thread | raw e-mail | index | archive | help
The other day a user here asked about increasing the per-process limit
for the maximum number of open file descriptors (they have a server process
that needs to have many file descriptors open at once for some periods of
time). I put together the following test program to demonstrate how
getrlimit() and setrlimit() could be used for this purpose:
#include <stdio.h>
#include <sys/time.h>
#include <sys/resource.h>
/* FreeBSD 1.1.5.1 brokenness. */
#ifdef RLIMIT_OFILE
#define RLIMIT_NOFILE RLIMIT_OFILE
#endif
#define MAXCONNECTIONS 1024
main ()
{
struct rlimit limit;
if (!getrlimit(RLIMIT_NOFILE, &limit))
{
printf ("Current soft file descriptor limit: [%d]\n",
limit.rlim_cur);
printf ("Current hard file descriptor limit: [%d]\n",
limit.rlim_max);
limit.rlim_cur = limit.rlim_max = MAXCONNECTIONS;
if (setrlimit(RLIMIT_NOFILE, &limit) == -1)
{
fprintf(stderr,"error setting max fd's to %d\n",
limit.rlim_cur);
perror("setrlimit");
exit(-1);
}
}
if (!getrlimit(RLIMIT_NOFILE, &limit))
{
printf ("New soft file descriptor limit: [%d]\n",
limit.rlim_cur);
printf ("New hard file descriptor limit: [%d]\n",
limit.rlim_max);
}
}
This attempts to set the number of permitted open file descriptors to
1024, which is only possible if the hard limit is equal to or higher
than that. I decided to try this program on all the platforms I had
around to see just how portable it would be. Turns out that it works
fine on just about all of them -- except FreeBSD. :(
In SunOS 4.1.3, Solaris 2.3, IRIX 5.2 and HP-UX 9.05, the program
behaves as expected: in SunOS the hard limit is 256, so the attempt
to raise the limit to 1024 fails with an error, as it should; in
Solaris 2.3 and HP-UX 5.2 the hard limit is exactly 1024, so the attempt
succeeds, as it should; it also succeeds in IRIX 5.2, where the limit is
2500. Changing the program so that it tries to exceed the hard limit
produces an error message and failure on all of these systems, again,
as it should.
In FreeBSD-current, weird things happen. I'll use freefall as an
example since I tested this program there. (The same behavior
shows up on my office machine, only my default limits are different
becase my system configuration isn't the same as freefall's.)
On freefall, I defined MAXCONNECTIONS to be 2048 instead of 1024 since
freefall's hard limit was higher than 1024.
getrlimit() reported that the soft file descriptor limit was 128 (which
is correct) and that the hard limit was -1 (which is thoroughly bogus).
The sysctl command showed that the hard limit was 1320. Attempting to
set the soft and hard limits to 2048 appeared to succeed, but reading
back the limits afterwards showed that both limits were maxed out at
1320. This behavior is not what I consider to be correct: the attempt
to raise the limits above the hard limit should have failed noisily;
instead it failed silently and the limits were trimmed at the hard
threshold. And the hard resource limit is most definitely being reported
incorectly. Why sysctl can see it properly but not getrlimit() I
have no idea. Yet.
On my 1.1.5.1 system at home, the results were a little different
but equally broken: instead of -1, getrlimit() reported the hard
limit to be something in the neighborhood of MAXINT. Aside from that,
it behaved the same as freefall, which is to say it screwed up.
Anybody else notice this? Better yet, anybody know how to fix it? :)
-Bill
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~T~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Bill Paul (212) 854-6020 | System Manager
Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research
Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Møøse Illuminati: ignore it and be confused, or join it and be confusing!
~~~~~~~~ FreeBSD 2.1.0-Development #0: Tue Feb 7 01:49:07 EST 1995 ~~~~~~~~~
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199502200656.BAA02173>