nginx update to 1.18.0 broke my wsl ubuntu 16.04 set up
brucek at gmail.com
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 mdounin.ru> wrote:
> 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
> > 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
> > 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
> > 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
> > 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
> 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 nginx.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the nginx