Hello!

On Thu, Jun 22, 2017 at 06:00:16AM -0400, Olaf van der Spek wrote:

> Note the connect(13, ...) and close(13) right after the response has been
> received.
> For PHP it's working, but AFAIK there's nothing in the FastCGI protocol that
> the backend has to do other then keeping the connection open.

[...]

> connect(13, {sa_family=AF_UNIX, sun_path="/tmp/backend.socket"}, 110) = 0
> getsockopt(13, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
> writev(13,
> [{iov_base="\1\1\0\1\0\10\0\0\0\1\1\0\0\0\0\0\1\4\0\1\3\344\4\0\17\36SCRIPT"...,
> iov_len=1040}], 1) = 1040

Just a note: FCGI_KEEP_CONN flag is set here, as per
"fastcgi_keep_conn on".

[...]

> recvfrom(13, "\1\6\0\1\7[\0\0Content-Type: applicatio"..., 4096, 0, NULL,
> NULL) = 1915
> readv(13, [{iov_base=0x561b1610558b, iov_len=2181}], 1) = -1 EAGAIN
> (Resource temporarily unavailable)
> writev(3, [{iov_base="HTTP/1.1 200 OK\r\nServer: nginx/1"..., iov_len=201},
> {iov_base="712\r\n", iov_len=5},
> {iov_base="\37\213\10\0\0\0\0\0\0\3\335\335Oo\334T\30\305\341}?E\325u\211\356?\277\347\274|\3"...,
> iov_len=1810}, {iov_base="\r\n", iov_len=2}], 4) = 2018
> close(13) = 0

And the connection is not closed by upstream server, as per
FCGI_KEEP_CONN flag. It is then closed by nginx for some reason
though.

Unfortunately, it is not possible to tell from the trace why the
connection is closed, as full upstream server response is not
available. Debugging log from nginx might be helpfull here, see
http://nginx.org/en/docs/debuggin_log.html.

In general, FastCGI connection might not be kept open by nginx if
an upstream server sent the response (closed the STDOUT stream),
but the connection is in a state which require additional handling
(for example, there was no END_REQUEST record). If you are using
some custom FastCGI implementation, this might be the case.

--
Maxim Dounin
http://nginx.org/
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx