Opened 10 years ago
Closed 10 years ago
#721 closed defect (invalid)
readv() failed (104: Connection reset by peer) while reading upstream does not try next upstream
| Reported by: | https://stackoverflow.com/users/573152/bernard-rosset | Owned by: | |
|---|---|---|---|
| Priority: | minor | Milestone: | |
| Component: | nginx-module | Version: | 1.6.x |
| Keywords: | Cc: | ||
| uname -a: | Linux 2.6.32-431.23.3.el6.x86_64 #1 SMP Thu Jul 31 17:20:51 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux | ||
| nginx -V: |
nginx version: nginx/1.6.1
built by gcc 4.4.7 20120313 (Red Hat 4.4.7-4) (GCC) TLS SNI support enabled configure arguments: --prefix=/usr/nginx16-vivarte-1.6.1 --with-http_addition_module --with-http_flv_module --with-http_gzip_static_module --with-http_gunzip_module --with-http_realip_module --with-http_stub_status_module --with-http_sub_module --with-http_ssl_module --with-http_degradation_module --with-http_geoip_module --with-http_random_index_module --with-http_secure_link_module --with-http_xslt_module --add-module=nginx_upstream_check_module-0.1.9 --add-module=nginx-sticky-module-1.2.5 --add-module=ngx_cache_purge-2.1 |
||
Description
Playing with a setup using nginx v1.6.1 and PHP-FPM v5.3.3, I noticed that when PHP-FPM was configured with a max_requests set to N, the Nth requests was drop in such a way nginx produced the following error:
readv() failed (104: Connection reset by peer) while reading upstream
A reply was then apparently sent to the client (Varnish) which translated the error into a 503.
However, several backends are defined in the upstream, and the other server(s) is (are) not checked.
There is no fastcgi_next_upstream directive configured in the configuration, thus the default value checking the next upstream on both error and timeout applies.
How come nginx sends an answer to the client without having checked the other(s) backend(s)?
Is it possible the fact that the owner having compiled the binary itslef, including 3rd-party modules, might have had an impact?
A quote from the documentation:
In the last case the message will be ending with
.. while reading response header from upstream, but in your case the headers have been read already.