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:
bluefox@icebox:~$ :(){ :|:|:; };:
How exactly does the ulimit work? Why do I seem to be able to evade
limits on maximum number of processes by doing a bigger fork bomb? I
would have thought that the above would have terminated much sooner,
since it was spawning x^3 processes instead of x^2 for iteration x and
should have hit 4096 a lot sooner.
--
We will enslave their women, eat their children and rape their
cattle!
-- Bosc, Evil alien overlord from the fifth dimension
Anti-Spam: https://bugzilla.mozilla.org/show_bug.cgi?id=229686
>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 first
and them spawning new ones everytime. To stop fork bombs, use killall -STOP
first, then kill them.
-`J'
--
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 first
> 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.
>
> -`J'
--
We will enslave their women, eat their children and rape their
cattle!
-- Bosc, Evil alien overlord from the fifth dimension
Anti-Spam: https://bugzilla.mozilla.org/show_bug.cgi?id=229686
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.
[email protected] wrote:
> 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.
>
I will test this later (sleeping now)
> 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.
I haven't gathered evidence; I rather look for evidence that fork() is
failing, like bash complaints. I get those in abundance in the first
case; but see none in the second case.
Trying again, I can't reproduce the phenomena. It crashes out in 3
seconds. Either just weird that it ran for so long last time before I
had to manually kill it off; or a race. I don't have sufficient data to
decide.
--
We will enslave their women, eat their children and rape their
cattle!
-- Bosc, Evil alien overlord from the fifth dimension
Anti-Spam: https://bugzilla.mozilla.org/show_bug.cgi?id=229686
On Dec 23 2006 19:42, John Richard Moser wrote:
>Jan Engelhardt wrote:
>>
>> Note that trying to kill all shells is a race between killing them all first
>> 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.
They don't just all die when you hit 4096. If you do nothing, 4096 +/- n will
stay around.
-`J'
--