FastCGI KeepAlive

Maxim Dounin mdounin at
Thu Jun 22 13:50:50 UTC 2017


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 

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

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

More information about the nginx mailing list