I've actually solved my problem with a better script, but I'm still left wondering why Apache2 hung completely - this is an out-of-the-box ISPCONFIG 3.03 install, everything bang up to date, running perfectly. Until...
The troublesome but innocent-looking script:
$fp = fopen("/var/log/ispconfig/cron.log", "r");
fseek($fp, -5000, SEEK_END);
$line_buffer = array();
while (!feof($fp)) {
$line = fgets($fp, 1024);
$line_buffer[] = $line;
$line_buffer = array_slice($line_buffer, -10, 10);
}
foreach ($line_buffer as $line) {
echo $line;
}
You get the idea, just a script I found on a forum somwehere. I did this for various logs, since it's a nice easy window on what's occurring (in a protect dir, of course!).
One day, the logs having grown large an me having sorted all my cron, scripting and mail queue errors, I thought I was time to start afresh. updated, rebooted, archived and deleted the logs. When I ran my script a couple of hours later, it hung. And hung. 8 minutes I waited. Chrome timed the page out, of course, but the server never came back to life. htop showed /usr/sbin/apache2 -k restart using 100% CPU. Never came back until I did a service apache2 restart.
Ran fine, as soon as I hit that logfile again...dead.
So, I worked out it was the logfile script, and I worked out that seeking beyond the end of the file wasn't good, and I found a better script http://www.php.net/manual/en/function.fseek.php#90450
But what I'm left wondering is... why didn't something restart or kill the process? How was one hanging page able to bring down the whole server?
It's running suphp. I say "out of the box", I've tweaked mysql and apache to fork and reserve sensible amounts of processes for the 512Mb RAM the VPS has, and it'll handle multiple refreshes of large pages, and hadn't hung before.
Any ideas how I'd avoid this? Google isn't my friend in this instance beyond the reccs. above about number of processes vs RAM available.
