unbit
qemu-x86_64 + uwsgi master socket full queue
So I'm sorry in advance for creating yet-another-issue. I'm sorry for creating an issue that's pretty challenging to debug. Hopefully though I've created an issue that's fairly easy to reproduce.
It is also 💯 ok to close this as won't fix, because more than likely the issue isn't actually in uWSGI it's probably a bit closer to the metal.
The Issue
When you run uWSGI on an M1 processor with qemu x86 emulation, socket 0 seems to immediately get a saturated queue:
docker run --platform linux/amd64 --rm -it -p 8080:8080 -p 8081:8081 flyinprogrammer/uwsgi-flask-demo:amd64
========== START UWSGI CONFIG ==========
[uwsgi]
disable-logging = true
http = :8080
module = app:app
stats-http = true
stats-server = 0.0.0.0:8081
master = true
processes = 4
single-interpreter = true
enable-threads = true
threads = 2
thunder-lock = true
uid = nobody
========== END UWSGI CONFIG ==========
[uWSGI] getting INI configuration from ./uwsgi.ini
*** Starting uWSGI 2.0.20 (64bit) on [Fri Feb 11 17:24:00 2022] ***
compiled with version: 10.2.1 20210110 on 11 February 2022 17:01:55
os: Linux-5.10.93-0-virt #1-Alpine SMP Thu, 27 Jan 2022 09:34:38 +0000
nodename: 69c8157b72b2
machine: x86_64
clock source: unix
pcre jit disabled
detected number of CPU cores: 6
current working directory: /opt/app
detected binary path: /usr/local/bin/uwsgi
setuid() to 65534
your memory page size is 4096 bytes
detected max file descriptor number: 1048576
lock engine: pthread robust mutexes
!!! it looks like your kernel does not support pthread robust mutexes !!!
!!! falling back to standard pthread mutexes !!!
thunder lock: enabled
uWSGI http bound on :8080 fd 4
uwsgi socket 0 bound to TCP address 127.0.0.1:40447 (port auto-assigned) fd 3
Python version: 3.9.10 (main, Feb 8 2022, 05:06:38) [GCC 10.2.1 20210110]
Python main interpreter initialized at 0x4000172cb0
python threads support enabled
your server socket listen backlog is limited to 100 connections
your mercy for graceful operations on workers is 60 seconds
mapped 416880 bytes (407 KB) for 8 cores
*** Operational MODE: preforking+threaded ***
WSGI app 0 (mountpoint='') ready in 1 seconds on interpreter 0x4000172cb0 pid: 10 (default app)
spawned uWSGI master process (pid: 10)
spawned uWSGI worker 1 (pid: 17, cores: 2)
spawned uWSGI worker 2 (pid: 19, cores: 2)
spawned uWSGI worker 3 (pid: 21, cores: 2)
spawned uWSGI worker 4 (pid: 22, cores: 2)
*** Stats server enabled on 0.0.0.0:8081 fd: 18 ***
spawned uWSGI http 1 (pid: 25)
Fri Feb 11 17:24:02 2022 - *** uWSGI listen queue of socket "127.0.0.1:40447" (fd: 3) full !!! (74256320/64) ***
Fri Feb 11 17:24:03 2022 - *** uWSGI listen queue of socket "127.0.0.1:40447" (fd: 3) full !!! (74256320/64) ***
Fri Feb 11 17:24:04 2022 - *** uWSGI listen queue of socket "127.0.0.1:40447" (fd: 3) full !!! (74256320/64) ***
Fri Feb 11 17:24:05 2022 - *** uWSGI listen queue of socket "127.0.0.1:40447" (fd: 3) full !!! (74256320/64) ***
Fri Feb 11 17:24:06 2022 - *** uWSGI listen queue of socket "127.0.0.1:40447" (fd: 3) full !!! (74256320/64) ***
^CSIGINT/SIGTERM received...killing workers...
It seems to only exist when master = true. And here's an example repo to reproduce the issue. The README.md should be pretty simple to follow.
Goals
-
Does someone want to show me how they'd debug this? or have any theories on how to fix it? I've been learning how uWSGI works for all of 24 hours, so while I'm eager to learn, I still have a lot of learning to do!
-
Maybe get this fixed, or figure out that it isn't us that's broken, but another "us" ? and help us fix that?
Happiness
Here's a picture of kookaburra baby because software is hard and animals are fun.
Did you get anywhere with this? Encountered the same issue when running uWSGI+django inside a docker container on a M1 host.
Anyone found a workaround for this? Encountered this error recently (docker container on M1 host)
