nginx update to 1.18.0 broke my wsl ubuntu 16.04 set up
brucek at gmail.com
Tue May 26 23:06:46 UTC 2020
Following up in case anyone with this same issue discovers this thread via
My problems went away once I added these two new directives to nginx.conf:
fastcgi_buffers 4 2048k;
I am not recommending this config for any production use or even any new
development setups. For myself, I'm happy to have this crutch so I can eke
out a little more life from my existing WSL 1 setup prior to the imminent
release of WSL 2.
On Tue, May 12, 2020 at 8:13 AM Bruce Klein <brucek at gmail.com> wrote:
> 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
>> > 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
>> > developer tools once the browser has timed out on waiting for the rest
>> > 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