Re: evading ulimits

[Valdis . Kletnieks]

On Sat, 23 Dec 2006 19:42:10 EST, John Richard Moser said:
> 
> 
> Jan Engelhardt wrote:
> >> I've set up some stuff on my box where /etc/security/limits.conf
> >> contains the following:
> >>
> >> @users          soft    nproc           3072
> >> @users          hard    nproc           4096
> >>
> >> I'm in group users, and a simple fork bomb is easily quashed by this:
> >>
> >> bluefox@icebox:~$ :(){ :|:; };:
> >> bash: fork: Resource temporarily unavailable
> >> Terminated
> >>
> >> Oddly enough, trying this again and again yields the same results; but,
> >> I can kill the box (eventually; about 1 minute in I managed to `/exec
> >> killall -9 bash` from x-chat, since I couldn't get a new shell open)
> >> with the below:
> > 
> > Note that trying to kill all shells is a race between killing them all firs
t
> > and them spawning new ones everytime. To stop fork bombs, use killall -STOP
> > first, then kill them.
> > 
> 
> Yes I know; the point, though, is that they should die automatically
> when the process count hits 4096.  They do with the first fork bomb;
> they keep growing with the second, well past what they should.

This may be another timing issue - note that in the first case, you have :|:
which forks off 2 processes with a pipe in between.  If the head process fails,
the second probably won't get started by the shell *either*.  In the second
case, you launch *3*, and it's possible that the head process will start and
live long enough to re-fork before a later one in the pipe gets killed.

Does the behavior change if you use 4095 or 4097 rather than 4096?  I'm
willing to bet that your system exhibits semi-predictable behavior regarding
the order the processes get created, and *which* process gets killed makes
a difference regarding how fast the process tree gets pruned.

Do you have any good evidence that the second version manages to create much
more than 4096 processes, rather than just being more exuberant about doing so?
I'm guessing that in fact, in both cases the number of processes ends up
pseudorandomly oscillating in the 4090-4906 range, but the exact order of
operations makes the rate and impact different in the two cases.

Attachment: pgp00000.pgp
Description: PGP signature