<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	xmlns:creativeCommons="http://backend.userland.com/creativeCommonsRssModule"
>

<channel>
	<title>Redio Blog &#187; fastcgi</title>
	<atom:link href="http://www.redio.info/blog/tag/fastcgi/feed" rel="self" type="application/rss+xml" />
	<link>http://www.redio.info/blog</link>
	<description>Das Communityblog von Redio</description>
	<lastBuildDate>Sun, 15 Nov 2009 13:21:47 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<creativeCommons:license>http://creativecommons.org/licenses/by-nc/3.0/de/</creativeCommons:license>
		<item>
		<title>Hallo mod_fcgid, tschüss mod_fastcgi</title>
		<link>http://www.redio.info/blog/2009/09/hallo-mod_fcgid-tschuss-mod_fastcgi.html</link>
		<comments>http://www.redio.info/blog/2009/09/hallo-mod_fcgid-tschuss-mod_fastcgi.html#comments</comments>
		<pubDate>Wed, 30 Sep 2009 08:16:52 +0000</pubDate>
		<dc:creator>PromyLOPh</dc:creator>
				<category><![CDATA[Technik]]></category>
		<category><![CDATA[azure]]></category>
		<category><![CDATA[fastcgi]]></category>
		<category><![CDATA[lexu]]></category>
		<category><![CDATA[mod_fastcgi]]></category>
		<category><![CDATA[mod_fcgid]]></category>

		<guid isPermaLink="false">http://www.redio.info/blog/promyloph/2009/09/hallo-mod_fcgid-tschuss-mod_fastcgi.html</guid>
		<description><![CDATA[Der Umbau ist komplett. Beide Server, azure gestern und lexu heute morgen, sind auf ein leicht modifiziertes mod_fcgid umgestellt worden. Modifiziert in der Hinsicht, dass die PHP-Authentifizierung wieder funktioniert und dass nicht für jeden vHost neue Worker gespawnt werden. Alles natürlich in der Hoffnung, dass die Umstellung die Probleme der Vergangenheit löst &#8212; so ganz [...]]]></description>
			<content:encoded><![CDATA[<p>Der Umbau ist komplett. Beide Server, azure gestern und lexu heute morgen, sind auf ein leicht modifiziertes mod_fcgid umgestellt worden. Modifiziert in der Hinsicht, dass die PHP-Authentifizierung wieder funktioniert und dass nicht für jeden vHost neue Worker gespawnt werden. Alles natürlich in der Hoffnung, dass die Umstellung die Probleme der Vergangenheit löst &#8212; so ganz sicher ist man sich da vorher aber nie&#8230;</p>
]]></content:encoded>
			<wfw:commentRss>http://www.redio.info/blog/2009/09/hallo-mod_fcgid-tschuss-mod_fastcgi.html/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>FastCGI klemmt</title>
		<link>http://www.redio.info/blog/2009/09/fastcgi-klemmt.html</link>
		<comments>http://www.redio.info/blog/2009/09/fastcgi-klemmt.html#comments</comments>
		<pubDate>Sun, 27 Sep 2009 12:59:51 +0000</pubDate>
		<dc:creator>PromyLOPh</dc:creator>
				<category><![CDATA[Technik]]></category>
		<category><![CDATA[fastcgi]]></category>
		<category><![CDATA[php]]></category>

		<guid isPermaLink="false">http://www.redio.info/blog/?p=29</guid>
		<description><![CDATA[Seit einiger Zeit beobachte ich dieses Phänomen nun schon: Plötzlich &#8212; wie aus dem Nichts &#8212; werden von FastCGI/PHP keine Anfragen mehr bearbeitet. Es gibt nur noch einen Timeout und den damit verbundenen &#8220;Internen Serverfehler&#8221;. So auch heute wieder zwischen 12:20 und 13:00 Uhr.
Typische Log-Einträge sind dann:
[error] FastCGI: comm with (dynamic) server "/usr/local/fcgi-bin/fcgi-php-user" aborted: (first [...]]]></description>
			<content:encoded><![CDATA[<p>Seit einiger Zeit beobachte ich dieses Phänomen nun schon: Plötzlich &#8212; wie aus dem Nichts &#8212; werden von FastCGI/PHP keine Anfragen mehr bearbeitet. Es gibt nur noch einen Timeout und den damit verbundenen &#8220;Internen Serverfehler&#8221;. So auch heute wieder zwischen 12:20 und 13:00 Uhr.</p>
<p>Typische Log-Einträge sind dann:</p>
<pre>[error] FastCGI: comm with (dynamic) server "/usr/local/fcgi-bin/fcgi-php-user" aborted: (first read) idle timeout (30 sec)
[error] FastCGI: incomplete headers (0 bytes) received from server "/usr/local/fcgi-bin/fcgi-php-user"</pre>
<p>oder auch</p>
<pre>[error] (4)Interrupted system call: FastCGI: comm with server "/usr/local/fcgi-bin/fcgi-php-user" aborted: select() failed
[error] FastCGI: incomplete headers (0 bytes) received from server "/usr/local/fcgi-bin/fcgi-php-user"</pre>
<p>Letztere Meldung lässt sich angeblich <a href="http://www.fastcgi.com/archives/fastcgi-developers/2009-January/000156.html">durch ein Update von mod_fastcgi</a> beheben. Das wird wohl auch für Redio mal fällig.</p>
<p><em>Update:</em> Ich sehe gerade, dass die Apache Foundation die Rechte an mod_fcgid übernommen hat und das Modul <a href="http://svn.apache.org/viewvc/httpd/mod_fcgid/">aktiv weiterentwickelt</a>. Das wäre sicherlich die bessere Alternative, als weiterhin auf mod_fastcgi zu setzen, das schon mehr als eine Jahr kein Update mehr erfahren hat.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.redio.info/blog/2009/09/fastcgi-klemmt.html/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
