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 <[email protected]> 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 <[email protected]> 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 >> [email protected] >> http://mailman.nginx.org/mailman/listinfo/nginx >> >
_______________________________________________ nginx mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx
