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:|
|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 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
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?