fastcgi freezing caused by UNB - Unclassified NewsBoard

Reply · Quote

splitbrain

2009-12-19, 21:25 #1

Member since Sep 2006 · 12 posts · Location: Berlin, Germany
Group memberships: Members

Show profile ·

Link to this post

Subject: fastcgi freezing caused by UNB

I'm running 20090606-dev on a Debian Lenny machine with PHP 5.2.11-0.dotdeb.1 and lighttpd 1.4.19-5. PHP is run via fastCGI.

I frequently experience lockups of fastCGI processes. After some research I believe it is caused by PHP Bug 45254.

The thing is, that the very same server runs quite a few different PHP applications and rarely triggers that bug. Only the forum fastCGI processes trigger it very frequently.

Additionally this was not happening with the UNB version I ran previously, which was 1.6.4.

Unfortunately the lockup is not easily reproducible. But from my experience it usually happens on posting. To be more exact, the post seems to be saved correctly, but the lockup happens somewhere after that.

My first idea was that this might be a problem with doing output or processing after sending a redirect header. So I patched unb_lib/common_out.lib.php around line 1813:

if (!rc('no_forward'))
{
// make absolute URL because this doesn't care about the <base href> attribute
if (!preg_match('_^([a-z]+):_i', $url) && rc('home_url'))
{
$baseUrl = TrailingSlash(rc('home_url'));
$baseUrl = preg_replace('_^https:_', 'http:', $baseUrl);
if ($_SERVER['HTTPS'] == 'on')
$baseUrl = preg_replace('_^http:_', 'https:', $baseUrl);
$url = $baseUrl . $url;
}
// Problems with duplicate Status header for PHP/FastCGI
#header('Status: 303'); // HTTP/303 "See other"
header('HTTP/1.1 303 See other');
header('Location: ' . $url);
exit(); ### PATCH code should immediatly exit after redirect ###
}

This seems to have lowered the number of lockups a bit but did not fix the issue completely.

I realize that this is probably a really hard to track down issue, since it only happens with a certain not too common setup and even then is not easily reproducible.

However I'd appreciate any hints on what was changed between 1.6.4 and 20090606-dev that would be run after saving a post and that would somehow might abort the browser connection but keeps the PHP script going (which is what seems to trigger the PHP bug).

PS: Now that I reread my post, I notice the comment about "Problems with duplicate Status header for PHP/FastCGI". Could that be related?

forum.dokuwiki.org

Reply · Quote

Yves (Administrator) 2009-12-20, 12:03 #2

User title: UNB developer & webmaster
Member since Jan 2004 · 3740 posts · Location: Erlangen, Germany
Group memberships: Administrators, Members

Show profile ·

Link to this post

First, I'm running PHP with FastCGI (and APC) on Debian (with Apache HTTPd) myself and never experienced an issue like this. Also, there's only been few changes in the recent past so you could possibly file-compare both versions to find the differences. I wouldn't remember anything that runs after such a redirect header.

There have been problems in the past with duplicate Status headers with FastCGI, but as far as I remember those were real errors that led to programme termination or something similar hard which made such a change absolutely necessary. But that was long ago...

♪ ...nanananah, all in all we’re just brilliant thieves, nanananah... ♪♬