Killing off Apache/php zombies

neerav

A while back, my host's server admin noticed that one script had a lot of processes running for 10,000 or 20,000+ seconds. Obviously not intended, but these zombies are piling up and I need to find a way to have them killed in the future from within the script.

Scenario: php as Apache module. User signs into site (3rd party proxy access script). Tries to download something using a download script, which uses cURL to retrieve the download, and passthru() it to the user . Some/many of the Apache processes run for ages. No complaints from any users, yet. Server admin not very happy. :glare: This didn't happen with php running as cgi.

Running a periodic cron script is out of the question (php can't kill apache processes). And that wouldn't really find the root of the problem anyway. I thought that after the php timeout of 30-90 seconds for whatever the reason, php and then the Apache process would just quit. Apparently not. :mad:

Is there any way to have the script properly kill itself in case it times out? Any other suggestions or ways to approach the problem? 😕

bradgrafelman

Well, if the script itself is actually still running, it must be stuck in a loop somewhere... though I would think that the PHP execution timer would kill it (is this directive set??).

Perhaps you could somehow design this script in a loop so that every xx seconds, it checks how long its been running, and if it's been running too long it [man]exit[/man]s.

I suppose the best solution would be to find why your script isn't terminating properly. Have you double checked for any infinite loops or anything? Is it a lot of code?

neerav

phpinfo says the times are set:

max_execution_time 30
max_input_time 60

There are no loops to get stuck on. It a straightforward script. The libraries, config, etc are also used elsewhere in a similar way without any problems. :bemused: For the scrutiny of hundreds of eyes, here's the script for feedback.

<?php
require_once("config.php");

$attid = (isset($_REQUEST["a"]))? $_REQUEST["a"] : 0;
$mid = (isset($_REQUEST["m"]))? $_REQUEST["m"] : 0;
$fname = (isset($_REQUEST["f"]))? $_REQUEST["f"] : 0;
$zipped = isset($_REQUEST["z"])? $_REQUEST["z"] : 0;

if ($attid && $mid && $fname) {
  $obj = new MyObject();
  //prime and prep the object's cookies 
  quick_init($obj);
  if ($obj->connect()) {         

	 if ($zipped) {
		header("Content-Type: application/octet-stream");
		header('Content-Disposition: attachment; filename="'.$mid.'.zip"');
		// retrieve download using cURL
		$obj->getAttachment($attid, $mid, "php://output", true);            

		exit();  

	 } else {
		$extension = strtolower(get_ext($fname));
		if ($extension == "jpg" or $extension == "jpeg") {
			header('Content-type: image/jpg');
		} elseif ($extension == "gif") {
			header('Content-type: image/gif');
		} elseif ($extension == "png") {
			header('Content-type: image/png');
		} else {
			header('Content-Disposition: attachment; filename="'.$fname.'"');
			header("Content-Type: application/octet-stream");
		} 
		// retrieve download using cURL
		$obj->getAttachment($attid, $mid, "php://output", false);            

		exit();
	 }
  }
}
echo "Download error.";

exit;

function get_ext($file_name) {
	$file_ext = array_pop(explode('.', $file_name));
	return $file_ext;
}


?>

neerav

A new thought. Is there some way to do $obj->getAttachment in the "background" so I can continue the script with a loop that would check every x seconds if it's still running and eventually kill the script after, say 5 minutes no matter what is happening?

dream_scape

Apache processes don't die when the script execution ends. They are persistent up to so many requests (set in httpd.conf), and then they will spawn a new child and kill themselves. And when PHP is running as an Apache module, the child process also holds onto memory that the script used until it [the Apache child] is killed.

If you killed all the Apache processes, how the heck would you serve any websites? It cannot serve them when it is dead.

And if you're sending files to the user to download, obviously the Apache child serving the file is going to be "active" while the file is being downloaded by the user. How large are the files?

Sounds more like you need to find a new server admin or host if your current one does not even understand the basics of how Apache works.

neerav

I trust my server admins/hosts. It my own understanding which is probably questionable. Instead of Apache process, maybe I should of said "one http request which is being served by Apache". The point is that the webserver "request" is kept active/open/running for 10,000+ seconds supposedly because the php script isn't quiting or timing out like it should after 30-60 seconds. See the snippet below.

Though the script and service can handle much larger, I have imposed limits of 250KB for download and 1MB for upload. With the thousands of times a day this particular script is run, there are only dozens of these long running requests. But dozens of "active" yet "idle" processes becomes an unnecessary burden on Apache.

This is a snippet of what the host gives me. After they send me this, the host admins, in their words, "killed the threads by restarting the apache process."

root@host [~]# scoreboard |grep mydomain.com
14691 R mydomain.com -0.17% 13151.45s POST /compose.php HTTP/1.0
14765 R mydomain.com -0.09% 14508.07s POST /compose.php HTTP/1.1
14768 R mydomain.com -0.10% 14332.53s POST /compose.php HTTP/1.1
7589 R mydomain.com -0.10% 5623.43s POST /compose.php HTTP/1.1
21165 R mydomain.com -0.12% 11749.70s POST /compose.php HTTP/1.0
[many more deleted]

Which looks like the problem is in the upload. Before I turned off downloads, the problem was mostly occuring with GETs, which led me to believe there is something wrong in the download part, which is the code I posted earlier. Either way my script, despite timeout limits in php and curl, are not timing out. :mad:

I hope this information makes the problem clearer. The direction I should take for the solution is all I ask for 🙂