nginx update to 1.18.0 broke my wsl ubuntu 16.04 set up

[Bruce Klein]

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.

Best,
Bruce

On Mon, May 11, 2020 at 7:54 PM Maxim Dounin <mdounin at mdounin.ru> 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"
> (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/
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20200512/627ee432/attachment.htm>