PHP scripts which 'terminate on their own'

software development

#1

Question

According to DreamHost Support, my PHP-based web app does not “terminate on it’s own”. Could someone enlighten me on exactly how one would go about modifying their app so that it does that?


#2

The obvious answer is

exit(0);

But something tells me there is more to this than that…


#3

Thanks for your suggestion. I thought it must be something like that as well, but since DreamHost Support insists that an outage on my server was caused by my application’s inability to terminate on its own, I thought I would give them the benefit of the doubt.

There are two primary response methods which account for all requests handled by the app. Both are handled in the Base controller from which all other controllers extend. The standard method ends with this:

[php]
// Render the page
header(‘Content-Type: text/html; charset=UTF-8’);
$this->dwoo->output($tpl, $dataset, $compiler);
exit;
[/php]

and the JSON method ends with this:

[php]
echo JSON::encode(array(‘status’ => ‘success’) + $this->dataset);
exit;
[/php]

So, I think I should be covered.

You are reading my mind.

I’m trying to track down the source of an extended outage (about 2 hours) during which 404 responses were sent out that were not created by my app. In fact, another site I have on the same server doesn’t bother to handle 404, so the generic Apache 404 response should show something like this:

Not Found
The requested URL /blah was not found on this server.
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.

However, on all of my sites on that server, the response was something new:

Not Found
The requested URL /cgi-system/php54.cgi/index.php was not found on this server.
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.

These are bizarre requests because none of my sites use a URL constructed of /cgi-system/php54.cgi/

The error logs indicate that there were roughly 800 unique requests during the outage. The show the following error from 11:47 to 13:07:

[Wed Oct 30 11:47:33 2013] [error] [client x.x.x.x] script not found or unable to stat: /dh/cgi-system/php54.cgi

The logs then recorded the following from 13:08 to 15:29:

[Wed Oct 30 13:08:07 2013] [error] [client x.x.x.x] PHP Warning:  PHP Startup: Unable to load dynamic library '/usr/local/php54/lib/php/extensions/no-debug-non-zts-20100525/imagick.so' - /usr/local/php54/lib/php/extensions/no-debug-non-zts-20100525/imagick.so: cannot open shared object file: No such file or directory in Unknown on line 0

Finally, the logs again recorded the following for a few seconds at 15:29 before the site returned to normal:

[Wed Oct 30 15:29:18 2013] [error] [client ​x.x.x.x​​] script not found or unable to stat: /dh/cgi-system/php54.cgi

DreamHost support has acknowledged that they were rolling out a new PHP binary around that time which can be seen here:

lrwxrwxrwx 1 root root 16 Oct 30 18:00 /usr/local/bin/php-5.4 -> ../php54/bin/php*
-rwxr-xr-x 1 root root 5.5M Oct 30 16:34 /usr/local/php54/bin/php*

but they are adamant that the extended outage was caused by me. The explanation is:

[quote]Your processes were still running when the upgrade was pushed and were
referencing the old package. When your processes were completely
terminated and reloaded, then they accessed the appropriate packages.[/quote]

This is curious because I have been benchmarking my script’s execution time for more than a year and with 8.5 million requests in the database, I can be quite confident that the app almost always finishes up its work in < 1s. Also, I don’t use FCGI and always explicitly close all connections for performance reasons (both produce a greater number of errors under load).

So, I’ve discussed this with Support in at least three emails, but they insist that the problem was caused by me. Rather than repeat the same argument with Support, I’m willing to concede that something in the design of all of my sites, not all using the same codebase, caused an extended outage due to the scripts not terminating on their own.

I just can’t figure out what that means and how I can fix it.

Any advice or ideas appreciated.


#4

Anyone? Anyone? Bueller?


#5

I’d think the freshly pushed package should have been loaded after the CGI timeout was reached.

Have they allowed persistent PHP processes on your account or something?


#6

I would think that would be the case as well. There may be a lag or delay with requests that were being processed at the instant of upgrading the package, but subsequent requests should have used the new package immediately. Each requests spawns its own process; there’s no FCGI or any process that runs after the request is completed.

Nope. Plain-vanilla shared hosting here.


#7

The logs tend to indicate that the update was performed manually and the operator ran into problems or a rollout script glitch’d out and was restarted multiple times. Could have been memory or disk access/thrashing issues. Whatever the case, I don’t see user code being a valid scapegoat here – unless you’ve devised a method to alter permissions on directories and files that root owns.


#8

That’s what I tried to explain to Support, but after three replies insisting that the problem was my fault, I decided to accept that possibility. I still don’t think there’s anything about my scripts which would cause the symptoms above, but I’m open to other opinions.