[Triage] v25.1.0 - supervisor tends to lose control over gunicorn

[ppfeufer]

Type

Bug Report

Description

After the update to v25.1.0, we see an increase in occasions where supervisor is losing control over the gunicorn process when supervisor is restarted, resulting in gunicorn not being shut down properly and blocking the port it's listening on.

Steps to Reproduce (for bugs)

• Update to v25.1.0
• Restart supervisor a couple of times

Configuration

In supervisor:

[program:gunicorn]
user = %(ENV_AA_USER)s
directory = %(ENV_AA_PROJECT_DIRECTORY)s
command = %(ENV_AA_COMMAND_GUNICORN)s %(ENV_AA_PROJECT_NAME)s.wsgi
    --workers 10
    --timeout 120
    --pid %(ENV_AA_GUNICORN_PIDFILE)s
stdout_logfile = %(ENV_AA_PROJECT_DIRECTORY)s/log/%(program_name)s.log
stderr_logfile = %(ENV_AA_PROJECT_DIRECTORY)s/log/%(program_name)s.log
autostart = true
autorestart = true
stopsignal = INT

Logs / Error Output

==> YF_Authentication_System/log/gunicorn.log <==
[2026-02-17 02:42:36 +0100] [1834139] [INFO] Starting gunicorn 25.1.0
[2026-02-17 02:42:36 +0100] [1834139] [ERROR] Connection in use: ('127.0.0.1', 8000)
[2026-02-17 02:42:36 +0100] [1834139] [ERROR] connection to ('127.0.0.1', 8000) failed: [Errno 98] Address already in use
[2026-02-17 02:42:37 +0100] [1834139] [ERROR] Connection in use: ('127.0.0.1', 8000)
[2026-02-17 02:42:37 +0100] [1834139] [ERROR] connection to ('127.0.0.1', 8000) failed: [Errno 98] Address already in use

After stopping supervisor, the gunicorn process keeps listening to its port, which prevents it from being started again, resulting in the above error.

» ps -aux | grep [p]ython
root         899  0.1  0.3 861284 52672 ?        Ssl   2025 246:53 /usr/bin/python3 /usr/bin/fail2ban-server -xf start
yf_auth  1833690  0.0  0.1 107932 23280 ?        S    02:36   0:00 /home/yf_auth/venv_311/auth/bin/python3 /home/yf_auth/venv/auth/bin/gunicorn YF_Authentication_System.wsgi --workers 10 --timeout 120 --pid /home/yf_auth/YF_Authentication_System/gunicorn.pid

Gunicorn Version

gunicorn v25.1.0

Python Version

Python 3.11 and 3.13

Worker Class

sync (default)

Operating System

Debian 12 (Py3.11) and Gentoo (Py3.13)

Additional Context

Downgrading to v25.0.3 resolves the issue again.

Checklist

• I have searched existing discussions and issues for duplicates
• I have checked the documentation and FAQ

[Geuthur]

Hi,

Did you tried it also with --no-control-socket

[ppfeufer]

Testing now …

[ppfeufer]

Yep, that seems to have done the trick.