nginx update to 1.18.0 broke my wsl ubuntu 16.04 set up

[Maxim Dounin]

Hello!

On Mon, May 11, 2020 at 09:38:12AM -1000, Bruce Klein wrote:

> Hi Maxim,
> 
> Thank you the reply, which I appreciate very much. I fully agree in spirit.
> 
> In practice, the issue of previous versions not working on WSL is a
> long-standing bug vs WSL that people far more expert than me on unix
> internals, WSL, nginx, and fpm have not yet solved for two years plus,
> other than everyone being told to disable fastcgi_buffering. (If you're
> interested, there's plenty of history in various WSL bug reports to read
> through.)
> 
> No doubt the root cause here is a flaw in WSL. That's not on the nginx team
> to fix.
> 
> That said, as a practical matter, the once easily available workaround is
> now gone. I'd like to understand what changed in 1.18 and if there is an
> easy adaptation to it, as that seems the path of least resistance.

To find out how to adapt a workaround - first you'll have to find 
out why the workaround used to work.  That is, what is the bug in 
WSL we are trying to work around.

Also note that it might not be a good idea to use things which 
depend on unexplained workarounds for flaws not fixed for years.  
As long as there is no explanation why the workaround work, this 
usually means that it can stop working unexpectedly and/or won't 
work in some edge cases.

> For what it's worth, the issue generates no logging in either the nginx
> error logs, access logs, or php7.1-fpm logs. It's impact is visible only on
> the web client side, where the user sees it as a partially received page
> and the net::ERR_INCOMPLETE_CHUNKED_ENCODING is available from the browser
> developer tools once the browser has timed out on waiting for the rest of
> the page.

So, the problem is that transfer stalls at some point, correct?  
This looks like an issue with sockets handling, and some things to 
try include:

1. Check the debug log to find out where things stall from nginx 
point of view.

2. Try different event methods, such as "select" and "poll" 
(http://nginx.org/r/use).  Note that this might require you to 
compile nginx yourself.

3. Play with socket-related options, such as tcp_nodelay 
(http://nginx.org/r/tcp_nodelay) and tcp_nopush 
(http://nginx.org/r/tcp_nopush).  Unlikely to help though.

4. Play with TCP buffers ("listen ... sndbuf=...", assuming it 
stalls somewhere while sending to the client) to see if it helps.  
Likely a buffer larger than the response size should help.

5. Play with "fastcgi_max_temp_file_size 0;" and/or "sendfile 
on/off".

As long as playing with buffering used to help somehow, this 
suggests that there is a problem with event reporting in the epoll 
emulation layer.  I don't think that this is something that can be 
fixed on nginx side, and any workarounds, including 
"fastcgi_buffering off", are likely to fail in some edge cases.  
The working solution might be to use other event methods though, 
such as "select" or "poll", see above.  Or to make sure that 
socket buffers are large enough to avoid blocking.

-- 
Maxim Dounin
http://mdounin.ru/