nginx update to 1.18.0 broke my wsl ubuntu 16.04 set up

[Bruce Klein]

Following up in case anyone with this same issue discovers this thread via
search:

My problems went away once I added these two new directives to nginx.conf:
fastcgi_buffer_size 1024k;
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.
>
> 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/20200526/32e137c8/attachment-0001.htm>