Crashing Servers with Loops

One of the easiest ways to crash a server is to create a program with a subroutine that just keeps caling itself. In a wost case scenario, the sub will create a file, hash or array that continues to grow as long as the program runs. Eventually this will crash the server.

It is unlikely that anyone would intentionally set up a loop that never ends. But it is sometimes very easy to do by accident. The fact that perl can be quickly modified and uploaded into immediate use is also one of the biggest causes of server problems.

Here is how a simple sub can be called to infinity.

#!/usr/bin/perl

#Call the subroutine
&countsomething;

sub countsomething {
$counter++;
&countsomething;
}

You can limit the server to shut down the program when it reaches a certain load level. In most shared hosting plans that will be the default so the chance of looping into a crash is unlikely. But on dedicated servers there is not usually a limit. If you limit how much cpu time a program can use, you will often stop many programs from working.

You always want to check your code to see if you have created a loop. If you have, you can alway put a limit in the sub to close after a certain number of calls. For example:

#!/usr/bin/perl

#Call the subroutine
&countsomething;

sub countsomething {
$counter++;
if ($counter > 10){exit;}
&countsomething;
}

This statement will close the program if it reaches 11 calls to the sub countsomething.

It seems like a simple concept and people do not belive they can make that type of mistake. But you will, and when you see the server hit loads of 300 or more and you realize you have created your own self inflicted denial of service attack you will pannic.

The chances become much more likely when you write a program that is much more complicated. Asking the program to call the sub if something else needs to be checked, but you forgot that if something else does not exist the program will loop out of control.

Just a heads up for the newbies that have not crashed a server yet.