nginx update to 1.18.0 broke my wsl ubuntu 16.04 set up

Bruce Klein brucek at
Tue May 12 18:13:32 UTC 2020

Thanks Maxim! I don't know if I'll be able to fix it with that but I'll
sure learn a lot trying. I appreciate all the pointers on where to look.


On Mon, May 11, 2020 at 7:54 PM Maxim Dounin <mdounin at> wrote:

> 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"
> (  Note that this might require you to
> compile nginx yourself.
> 3. Play with socket-related options, such as tcp_nodelay
> ( and 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
> _______________________________________________
> nginx mailing list
> nginx at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the nginx mailing list