*AMP and Runaway Scripts
Peter Zaitsev posted a very interesting test on how PHP and Apache handle runaway PHP scripts.
I'm sure all of us have had a long executing SQL script or at least a runaway script, and he points out even with ignore_user_abort set to FALSE and max execution times set both in PHP and Apache, a runaway SQL query can execute beyond the timeouts, even when aborted by the user (stop button on the browser).
Even using the function connection_aborted() to check for a user abort fails.
However, the script will cease on a user abort if it performs regular ob_flush(); flush(); commands. For example:
<?php echo("Hello"); for($i=0;$i<10000;$i++) { sleep(1); echo('.'); ob_flush(); flush(); } ?>
Just one more reason why I love the MySql Performance Blog.
only_samurai:
This is useful for more than just process control. A poorly written script could be exploited in a Denial of Service attack. In an open source project, where an attacker could analyze code for just such a scenario, this would be a great redundant feature. Even if, as some of the comments suggest, Apache or PHP takes care of run away threads, redundancy is a key tool in any developer’s arsenal against malicious individuals.
22 May 2008, 8:53 pmSamuraiNet Blog » Blog Archive » Reading Rainbow: Episode 7:
[...] I read this post on a friend of mine’s blog and thought it was rather useful. I’ve had PHP scripts running on cron before that had exactly this problem. They would lock up after a while and before I knew it, I had about 15 “undead” PHP processes just eating up my CPU. What was worse was that my shared host only allowed each user 15 processes at the same time, so slowly but surely the rest of my sites would go down. http://www.toosweettobesour.com/2008/05/21/amp-and-runaway-scripts/ [...]
25 May 2008, 2:33 pm