Preventing Accidentally Fork Bombing My Box

[Dan Anderson]

I'm creating an app that uses forks in a number of places to do things
quicker. Unfortunately, I have a bad habit of accidentally fork bombing
my box. Is there any way I can run a perl process (even if it's a Linux
command) so that it wont eat up all available resources if I screw up?
Or do I just need to learn to be more careful?

-Dan

[Tom Kinzer]

use safe ?

just a guess if it will work for this problem. check it out.

-Tom Kinzer

-----Original Message-----
From: Dan Anderson [mailto:dan@mathjunkies.com]
Sent: Friday, December 19, 2003 8:56 AM
To: Perl Beginners
Subject: Preventing Accidentally Fork Bombing My Box


I'm creating an app that uses forks in a number of places to do things
quicker. Unfortunately, I have a bad habit of accidentally fork bombing
my box. Is there any way I can run a perl process (even if it's a Linux
command) so that it wont eat up all available resources if I screw up?
Or do I just need to learn to be more careful?

-Dan


--
To unsubscribe, e-mail: [email]beginners-unsubscribe@perl.org[/email]
For additional commands, e-mail: [email]beginners-help@perl.org[/email]
<http://learn.perl.org/> <http://learn.perl.org/first-response>

[Tom Kinzer]

nope, looks like it's no safety net for CPU or anything, just
compartmentalized namespace and such.

-Tom Kinzer

-----Original Message-----
From: Tom Kinzer [mailto:tomkinzer@earthlink.net]
Sent: Friday, December 19, 2003 9:27 AM
To: Dan Anderson; Perl Beginners
Subject: RE: Preventing Accidentally Fork Bombing My Box


use safe ?

just a guess if it will work for this problem. check it out.

-Tom Kinzer

-----Original Message-----
From: Dan Anderson [mailto:dan@mathjunkies.com]
Sent: Friday, December 19, 2003 8:56 AM
To: Perl Beginners
Subject: Preventing Accidentally Fork Bombing My Box


I'm creating an app that uses forks in a number of places to do things
quicker. Unfortunately, I have a bad habit of accidentally fork bombing
my box. Is there any way I can run a perl process (even if it's a Linux
command) so that it wont eat up all available resources if I screw up?
Or do I just need to learn to be more careful?

-Dan


--
To unsubscribe, e-mail: [email]beginners-unsubscribe@perl.org[/email]
For additional commands, e-mail: [email]beginners-help@perl.org[/email]
<http://learn.perl.org/> <http://learn.perl.org/first-response>



--
To unsubscribe, e-mail: [email]beginners-unsubscribe@perl.org[/email]
For additional commands, e-mail: [email]beginners-help@perl.org[/email]
<http://learn.perl.org/> <http://learn.perl.org/first-response>

[Drieux]

On Dec 19, 2003, at 8:55 AM, Dan Anderson wrote:
[..]

> I'm creating an app that uses forks in a number of places to do things
> quicker. Unfortunately, I have a bad habit of accidentally fork
> bombing
> my box.

I'm not sure I get this phrase 'fork bombing' to begin with,
do you mean that you wind up forking more processes till you
over run the kernel's process table and then things start
dying off in 'un-natural states'? Or that you forgot to
do appropriate thing with managing your SIG_CHLD so that
you are not over running the kernel's process table with
a bunch of zombie processes that could be harvested?

cf perldoc perlipc

> Is there any way I can run a perl process (even if it's a Linux
> command) so that it wont eat up all available resources if I screw up?
> Or do I just need to learn to be more careful?

Actually, no. If your linux boxes is rigged to
have various limits set, then there are some ways
to prevent a given process/user from over-running
more than that limit. But if one writes bad code, there
is almost nothing that perl can do to protect you
from your code.

What you may want to think about is rigging your
code to have a '$max_child' and that the parent
will wait on any new forks until that value is decremented.

In like manner, the 'child process' so forked, would
be limited to either

a. not Forking any children
b. no more than ($max_child - 1) number of children
then the problem is mostly factorial...

You might also strategize with say semaphours so that
all of the processes would be able to deal with getting
a common head count - but that way also leads to weirdneff
as to who keeps the write on the semaphours...

You could also try to limit some of your madness by
doing a pipe and fork, as you will might possibly
bump into the FD limit before you 'fork bomb' your box.
In this strategy the parent has some chance of being
the negotiator of what is going on...

ciao
drieux

---

[Dan Anderson]

drieux <drieux@wetware.com> writes:

> On Dec 19, 2003, at 8:55 AM, Dan Anderson wrote:
> [..]

> > I'm creating an app that uses forks in a number of places to do things
> > quicker. Unfortunately, I have a bad habit of accidentally fork
> > bombing
> > my box.

>
> I'm not sure I get this phrase 'fork bombing' to begin with,

I'll do something dumb, like fork in a loop while
$number_forks < $fork_this_many. But, for whatever reasons, I have a
tendency to do things like create an infinite loop by accident, and
fork an infinite number of processes, or soemthign like that. This
results in what is effectively a DOS on my box, because it starts
swapping as soon as it eats up all the RAM and is unresponsive without
a hard reboot. :-(

Now, try as I might to prevent these, in the same way that
every once in a while I leave an infinite loop on a normal program or
do something similarly dumb, when I do it with forks I have a tendency
to eat up resources until I get DOSed. So instead of spending the 30
seconds killing the process, looking into the code, cursing myself,
and fixing it, I end up hard rebooting and recovering all my autosaved
files. :-(

-Dan

[Bob Showalter]

Dan Anderson wrote:

> I'm creating an app that uses forks in a number of places to do things
> quicker. Unfortunately, I have a bad habit of accidentally
> fork bombing
> my box. Is there any way I can run a perl process (even if
> it's a Linux
> command) so that it wont eat up all available resources if I
> screw up?
> Or do I just need to learn to be more careful?

FreeBSD has a limits(1) command for this. I don't use Linux, so I don't know
if it has a similar thing...

[Drieux]

On Dec 19, 2003, at 11:33 AM, Dan Anderson wrote:
[..]

> I'll do something dumb, like fork
> in a loop while $number_forks < $fork_this_many.

[..]

You might want to have a WAY different strategy!

Remember both sides of the fork get a copy of
the code space - and as such the first forked
child can think that it is the parent, and
it too is going to do the same loop.... at which
point each of them are trying to spawn off MORE
children, and no one remembers to exit...

Go back and peek at:
<http://www.wetware.com/drieux/pbl/Sys/gen_sym_big_dog.txt>
The child processes are going to be executing a specific
body of Code and not 'all' of the code.

If you peek at the runner() method, I have made it
a bit clearer that any of the dispatched code is
suppose to have it's own 'exit()' call - and that
on the child side of the call IF that 'fails' the
next piece of code that would be called would be

exit(-1);

so that we have at least some gurantee that the
children will not go running around forking like mad.

So while it IS true that we have the dispatcher

$process{$cmd}($cmd,$args);

inside the infinite loop "while(1) BLOCK" one
of the processes is a 'quit' and there are
some that will fork children. But the code that
the child can execute is limited.

The other idea you might really want to
deal with is what is known as a 'co-operative
multi-tasking group' - so that rather than
fork N processes you have an init script
style solution that will spawn a process as
the process leader, that will spawn and delegate
to N processes incoming new requests. One variant
of this strategy is how most web-servers work, where
there is httpd will spawn off N-processes, and pass
the connection off to another process. This saves
on the fork time as well as provide a more reasonable
control over SDOS ( self denial of servicing ).



ciao
drieux

---

[R. Joseph Newton]

Dan Anderson wrote:

> I'm creating an app that uses forks in a number of places to do things
> quicker. Unfortunately, I have a bad habit of accidentally fork bombing
> my box.

This is a pretty good sign that you are over-using the fork command.
Efficiently designed programs can usually run pretty well without extra
forking. If a certain process can do its work independtently of the rest of
the program, and one or the other needs to wait for some external event
[such as user input], that would be a good case for using a fork, very
carefully. I can't see a good reason to ever fork processes from inside a
loop. That is just asking for trouble.

So is speed really an issue for you?

Joseph

[George Schlossnagle]

On Dec 20, 2003, at 12:58 AM, R. Joseph Newton wrote:

> Dan Anderson wrote:
>

>> I'm creating an app that uses forks in a number of places to do things
>> quicker. Unfortunately, I have a bad habit of accidentally fork
>> bombing
>> my box.

>
> This is a pretty good sign that you are over-using the fork command.
> Efficiently designed programs can usually run pretty well without extra
> forking. If a certain process can do its work independtently of the
> rest of
> the program, and one or the other needs to wait for some external event
> [such as user input], that would be a good case for using a fork, very
> carefully. I can't see a good reason to ever fork processes from
> inside a
> loop. That is just asking for trouble.

Many (I would dare so most) real-world forking examples involve calling
fork() in a (albeit small) loop. Think pre-fork servers, or
maintaining a pool of helper children, etc. This is hands-down the
easiest strategy for dealing with slow operations that never block
(disk IO) and is often easier to understand than writing an event-based
framework for IO that can be done in a non-blocking fashion (network
IO).

Obviously forking in a tight loop with no controls over your child
dispatching is a bad thing, but I assume that Dan's question was along
the lines of _accidentally_ fork bombing his machine with code like

for(1...$num_children) {
unless(fork()) {
child_main();
# oops forgot to exit here
}
}

which will fork-bomb your machine.

As far as preventing errors like that in development, you can use
something like Proc::Queue (I've never used it, but it seems to be a
direct fit). Alterntively you can monitor the process table and ensure
that you do not exceed a certain number of processes in your parent
process' process group.

George


// George Schlossnagle
// Postal Engine -- [url]http://www.postalengine.com/[/url]
// Ecelerity: fastest MTA on earth