FastCGI KeepAlive

[Maxim Dounin]

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/