Opened 9 years ago

Closed 9 years ago

#721 closed defect (invalid)

readv() failed (104: Connection reset by peer) while reading upstream does not try next upstream

Reported by: 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


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?

Change History (1)

comment:1 by Valentin V. Bartenev, 9 years ago

Resolution: invalid
Status: newclosed

A quote from the documentation:


an error occurred while establishing a connection with the server, passing a request to it, or reading the response header;

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.

Note: See TracTickets for help on using tickets.