Re: maximum number of processes on kernel 2.4.x

[Wayne Tucker <wtucker@donobi.com>]

On Tue, Mar 12, 2002 at 02:52:36AM +0100, Russell Coker wrote:
> On Tue, 12 Mar 2002 02:33, Wayne Tucker wrote:
> > > I guess that you have some problem related to ulimit...
> >
> > [snip]
> >
> > Is the "default" number of processes allowed by ulimit/setrlimit
> > determined in the kernel, or is it being set from somewhere in the
> > init scripts?  Are resource limits inherited from the parent process,
> > and can the default for daemons be changed somewhere in the init
> > process so that they can be effective for daemon processes that start
> > on bootup?  The system does not have any users other than admins, so
> > for our purposes it would be safe for us to have RLIMIT_NPROC set to
> > something higher such as 512.
> 
> I think that generally ulimit is not set in init scripts.  However some init 
> scripts may end up sourcing /etc/profile (this is not a good idea), and 
> people often put ulimit commands in /etc/profile...
> 
> The kernel definately doesn't put any significant limits in.
> 
> Are you certain that it's a limit on the number of processes?  Or might it be 
> some other limit that hits in when you have 256 processes?
> 
> Check in /proc/sys/fs and see if the first field in file-nr is near the value 
> of file-max.  Also do the same check for inode-max if it exists.


The limit of 256 is coming from the `ulimit -s` command (bash).  Just
as a test, I also threw together a program to call getrlimit and
display the result.  Here's what I get:

wayne@ironman:~$ cat /proc/version
Linux version 2.4.17 (root@ironman) (gcc version 2.95.4 20011006 (Debian prerelease)) #1 Wed Jan 2 21:55:45 PST 2002
wayne@ironman:~$ ./showrlimit
cur: 256 max: 4294967295

(now I really understand what you mwant when you said that my system
would be dead long before it got there ;)

I thought that this may have been coming from somewhere in bash, so I
set up another account using tcsh, but I get the same result.  I also
ran an strace on bash, but I don't see any getrlimit calls in there.

The system is running woody, and most of the init scripts are
untouched.  Interestingly enough, this is what I get on a system that
is running potato with (Adrian?) Bunk's 2.4-series kernel packages:

groucho:~$ cat /proc/version
Linux version 2.4.14 (root@ironman) (gcc version 2.95.4 20011006 (Debian prerelease)) #1 Fri Nov 9 10:44:55 PST 2001
groucho:~$ ./showrlimit
cur: 2038 max: 2038

It doesn't seem to be a kernel issue, either, as I this is what I get
on another woody system:

harpo:~$ cat /proc/version
Linux version 2.4.14 (root@ironman) (gcc version 2.95.4 20011006 (Debian prerelease)) #1 Fri Nov 9 10:44:55 PST 2001
harpo:~$ ./showrlimit
cur: 256 max: 4294967295

The hardware in these last 2 machines is virtually identical, with the
exception of the latter one having a larger hard drive.


If I do a ulimit -n 1024 and then su to another account, RLIMIT_NPROC
is set back to 256.  I'm trying to figure out how to run strace on the
su session, but I can't get it to take the password.

Here's the code that I used to call getrlimit:

#include <sys/time.h>
#include <sys/resource.h>
#include <unistd.h>
#include <stdio.h>

int main(void) 
{
	struct rlimit rlimit_cur;

	getrlimit(RLIMIT_NPROC, &rlimit_cur);
	printf("cur: %lu max: %lu\n", rlimit_cur.rlim_cur, rlimit_cur.rlim_max);
	return(0);
}


Any thoughts?

Many thanks,

Wayne


-- 
Wayne A. Tucker - wtucker@donobi.com
Network Engineer, Donobi Inc.