Gunicorn - "Resource temporarily unavailable"
Updated 2026-08-08: explained why gunicorn’s own backlog setting doesn’t fix this.
Are you seeing this error in your logs while your server is under high load?:
[error] 10#0: *14843 connect() to unix:/tmp/gunicorn.sock failed (11: Resource temporarily unavailable) while connecting to upstream, client: 192.0.2.10, server: , request: "GET / HTTP/1.0", upstream: "http://unix:/tmp/gunicorn.sock:/", host: "198.51.100.20"
I ended up making an example dockerfile with nginx + gunicorn + flask to reproduce this problem: https://github.com/pawl/somaxconn_test
Bumping the net.core.somaxconn setting ended up fixing it.
Error 11 is EAGAIN, and on a connect() to a unix socket it means the listening socket’s accept queue is full. Connections sit in that queue after the kernel accepts them and before gunicorn calls accept(), so it fills up whenever requests arrive faster than the workers drain them. Once it’s full the kernel refuses new connections instead of queueing them, and nginx reports the refusal as this error.
net.core.somaxconn is the ceiling on how deep that queue is allowed to be. Linux capped it at 128 until kernel 5.4 raised the default to 4096, so on anything older this is a low bar to hit.
The part that cost me the most time is that gunicorn’s own --backlog defaults to 2048, which looks like plenty. listen(2) silently truncates whatever a process asks for down to somaxconn, so gunicorn requested 2048 and got 128, with nothing in any log to say so. Raising the sysctl is what actually changes the queue:
sudo sysctl -w net.core.somaxconn=4096
Put it in a file under /etc/sysctl.d/ to survive a reboot. In a container it’s a property of the network namespace rather than the image, so it’s docker run --sysctl net.core.somaxconn=4096, or set on the host if the container shares its network namespace.
Worth saying that a full accept queue is usually a symptom. If the workers can’t keep up, the queue depth buys headroom for a traffic spike, not for a slow application.