Hi Maxim!, once again thank you... <div><br></div><div>Exactly what I thought.. but something doesn't make sense, the owner of the site put some paid traffic on it and I now numbers are bigger than before, it could not be that hundreds of people abort the connection exactly and precisely at the same byte. It's always the same byte, and it's always random thought I've never been able to reproduce it myself. Just sniffed others traffic to see it.</div>

<div><br></div><div>Just checked and there's no mention of proxy_ignore_client_abort either on frontend (nginx load balancer) or backend (nginx proxy for php-fpm). This is really weird....</div><div><br></div><div>I think I still have the original debug logs from where that grep came from, will check it out as soon I can ssh into it.</div>

<div><br></div><div>Thank you once again!!</div><div><br></div><div>Guzmán</div><div><br></div><div><br><div><br><br><div class="gmail_quote">On Thu, Aug 9, 2012 at 3:26 PM, Maxim Dounin <span dir="ltr"><<a href="mailto:mdounin@mdounin.ru" target="_blank">mdounin@mdounin.ru</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello!<br>
<div class="im"><br>
On Thu, Aug 09, 2012 at 12:10:57PM -0300, Guzmán Brasó wrote:<br>
<br>
> Hi Maxim! Thanks for taking time to check it out...<br>
><br>
> So the 499 seen by the php-fpm nginx here It's not that main nginx closed<br>
> the connection but that fastcgi closed the connection?<br>
><br>
> All the time thought was nothing to do with the backend... there's no php<br>
> warning or error on the php-fpm side when this happens, will try to enable<br>
> debug mode in php-fpm and swim around the logs....<br>
<br>
</div>Ah, sorry, it looks like I've misunderstood what you were trying<br>
to say.  Partialy because of strange usage of the "upstream" word -<br>
from frontend point of view it's more or less synonym for<br>
"backend", you probably mean to say "frontend" instead.<br>
<br>
Looking though debug log you've provided earlier suggests that<br>
everything is actually ok.  Here is quote from frontend logs:<br>
<div class="im"><br>
> 2012/08/03 13:25:45 [debug] 1546#0: *823 http proxy header done<br>
> 2012/08/03 13:25:45 [debug] 1546#0: *823 HTTP/1.1 200 OKM<br>
> 2012/08/03 13:25:45 [debug] 1546#0: *823 finalize http upstream request: -1<br>
> 2012/08/03 13:25:45 [debug] 1546#0: *823 finalize http proxy request<br>
<br>
</div>The intresting part is somewhere between "HTTP..." and "finalize<br>
..." lines, but it's at low level and was misssed from grep.  Most<br>
likely (assuming request finalization is for reason) client closed<br>
request and this resulted in writev() failure.  This in turn<br>
caused finalization of a request, and close of the connection to<br>
the upstream server (aka backend).  There are 0 bytes sent as<br>
nothing was actually sent.  The fact that you see many such log<br>
lines suggests that you've probably disabled client abort checks<br>
(proxy_ignore_client_abort).<br>
<br>
On a backend you see this as "200" with some small number of bytes<br>
which is some first bytes it was able to send before connection<br>
was closed by the frontend.  The 499 finalization is internal, and<br>
as response status as sent to client is already 200 - it doesn't<br>
affect access log.<br>
<div class="HOEnZb"><div class="h5"><br>
Maxim Dounin<br>
<br>
_______________________________________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org">nginx@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx</a></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Guzmán Brasó Núńez<br>

Senior Perl Developer / Sysadmin<br>Web: <a href="http://guzman.braso.info">http://guzman.braso.info</a><br>Mobile: +598 98 674020<br>
</div></div>