Nothing. There&#39;s nothing in the logs.<br><br>According to the mongrel mailing list, it can raise 500s when it&#39;s in err state. But, does it respond with an incorrect error code? I dunno.<br><br>I mean, I&#39;m not seeing anything in any error logs, and nginx is reporting a 200 for all requests. wtf?<br>
<br><div class="gmail_quote">On Mon, Mar 10, 2008 at 10:17 AM, Aníbal Rojas &lt;<a href="mailto:anibalrojas@gmail.com">anibalrojas@gmail.com</a>&gt; wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
But what does the production.log or mongrel logs say?<br>
<br>
I mean, can you find errors in the backend logs matching the date/time<br>
for the errors in the nginx log?<br>
<font color="#888888"><br>
--<br>
Aníbal Rojas<br>
<a href="http://hasmanydevelopers.com" target="_blank">http://hasmanydevelopers.com</a><br>
<a href="http://rubycorner.com" target="_blank">http://rubycorner.com</a><br>
<a href="http://anibal.rojas.com" target="_blank">http://anibal.rojas.com</a><br>
</font><div><div></div><div class="Wj3C7c"><br>
On Tue, Mar 11, 2008 at 9:17 AM, James Golick &lt;<a href="mailto:jamesgolick@gmail.com">jamesgolick@gmail.com</a>&gt; wrote:<br>
&gt; Nothing... all of the mongrels respond normally when hit without nginx.<br>
&gt;<br>
&gt; This has got to be an nginx issue...<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Mon, Mar 10, 2008 at 9:40 AM, James Golick &lt;<a href="mailto:jamesgolick@gmail.com">jamesgolick@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; Yeah, I don&#39;t think it&#39;s mongrel, as they&#39;re all started the identical way<br>
&gt; (thru a process monitor).<br>
&gt; &gt;<br>
&gt; &gt; Also, every time I get the error, I see one of those issues in the nginx<br>
&gt; error.log. But, I guess it still could be happening upstream....<br>
&gt; &gt;<br>
&gt; &gt; I will test them all and report back.<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; On Mon, Mar 10, 2008 at 9:29 AM, Phillip B Oldham<br>
&gt; &lt;<a href="mailto:phill@theactivitypeople.co.uk">phill@theactivitypeople.co.uk</a>&gt; wrote:<br>
&gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; I was seeing something similar with PHP5 fastcgi and lighttpd, though it<br>
&gt; was a lot more than 10% - maybe 25-50. I&#39;m getting a little worried as I<br>
&gt; think I may be seeing the same thing at around 5-10% with nginx.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; During my investigations into why this was happening in lighttpd, I came<br>
&gt; across the following paragraph in the mod_fcgi docs:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Adds a MaxRequestsPerProcess parameter that allows mod_fcgid to exit<br>
&gt; after handling a certain number of requests, similar to the existing<br>
&gt; ProcessLifeTime option.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; This solves a problem with PHP in FastCGI mode. By default, PHP stops<br>
&gt; accepting new FastCGI connections after handling 500 requests;<br>
&gt; unfortunately, there is a potential race condition during the PHP cleanup<br>
&gt; code in which PHP can be shutting down but still have the socket open, so<br>
&gt; mod_fcgid under heavy load can send request number 501 to PHP and have it<br>
&gt; &quot;accepted&quot;, but then PHP appears to simply exit, causing errors. Not too<br>
&gt; sure if your rails app/mongrel is restarting processes after a set limit and<br>
&gt; coming across the same race condition?<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; If this problem is could become aparent in nginx it would be great if<br>
&gt; there was a plugin to spawn and manage fcgi threads which could limit the<br>
&gt; number of connections to each backend.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; HTH.<br>
&gt; &gt; &gt; Phill<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; James Golick wrote:<br>
&gt; &gt; &gt; I have nginx running as a proxy to about twelve upstream app servers,<br>
&gt; serving a rails app. Nothing else really in this configuration.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; I am seeing about 10% of requests throwing 500 errors, and this in my<br>
&gt; error log:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; 2008/03/10 08:41:05 [info] 6632#0: *12005 client closed prematurely<br>
&gt; connection while sending response to client, client: xxx, server: xxx,<br>
&gt; request: xxx, host: xxx, referrer: xxx<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; I&#39;m also seeing lots of:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; client xxx closed keepalive connection<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; but that strikes me as normal, and I&#39;m seeing:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; client closed prematurely connection while reading client request line,<br>
&gt; client: xxx, server: xxx<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; I have googled far and wide, and the best answers I came up with were to<br>
&gt; add these lines to my conf:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; proxy_ignore_client_abort &nbsp;on;<br>
&gt; &gt; &gt; proxy_next_upstream error;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; but, that doesn&#39;t seem to have solved the problem.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Any ideas?<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Thanks in advance.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; --<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Phillip B Oldham<br>
&gt; &gt; &gt; The Activity People<br>
&gt; &gt; &gt; <a href="mailto:phill@theactivitypeople.co.uk">phill@theactivitypeople.co.uk</a> ________________________________<br>
&gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Policies<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; This e-mail and its attachments are intended for the above named<br>
&gt; recipient(s) only and may be confidential. If they have come to you in<br>
&gt; error, please reply to this e-mail and highlight the error. No action should<br>
&gt; be taken regarding content, nor must you copy or show them to anyone.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; This e-mail has been created in the knowledge that Internet e-mail is<br>
&gt; not a 100% secure communications medium, and we have taken steps to ensure<br>
&gt; that this e-mail and attachments are free from any virus. We must advise<br>
&gt; that in keeping with good computing practice the recipient should ensure<br>
&gt; they are completely virus free, and that you understand and observe the lack<br>
&gt; of security when e-mailing us. ________________________________<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
<br>
</div></div></blockquote></div><br>