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 - [EMAIL PROTECTED]
Network Engineer, Donobi Inc.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
