Jan. 27th, 2005

giza: Giza White Mage (Default)
So... we're working on a Big Project at my $DAYJOB, and getting close to releasing it. One the parts that I'm responsible for is the web interface. Well, the other day we got a frantic call from our boss who was at a trade show. It seems that he tried running the software update program, which spent 2 minutes timing out because the box wasn't connected to the Internet. The problem that he was having was that Apache became unresponsive on that box while waiting for the updater to time out. Now, we're just talking about calling popen() from a PHP script. There's no reason why the parent Apache process or any of the sibling processes should be affected.

Just on a hunch, I checked out the documentation for popen() and found a link to bug #22526. It turns out that if you call session_start() to establish a session and then call popen(), any calls to session_start() from other scripts will block until the process in the first script is finished. And, since every page on our system sets up a session right off the bat (to fetch security information and whatnot), the creates the appearance that Apache itself has gone kaput. Talk about unexpected interactions between software components.

The workaround we used was something along the lines of:

session_start();
...
session_write_close();
$fp = popen(foo);
...
$retval = pclose($fp);
session_start();

It's kinda nasty, but it completely fixed the problem we were having.

Clearly, my code's purpose in life is to serve as a warning to others. :-)

Profile

giza: Giza White Mage (Default)
Douglas Muth

April 2012

S M T W T F S
1234567
891011121314
15161718192021
22232425262728
2930     

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags