Gunicorn and systemd socket with a runner (like uv)

[RemiDesgrange]

I've scratched my head around this issue and don't know if this is normal behavior, nor if I need to submit an issue for this.

I have a superset app

The nginx config:

upstream superset_app_server {
    # fail_timeout=0 means we always retry an upstream even if it failed
    # to return a good HTTP response

    # for UNIX domain socket setups
    server unix:/run/superset.sock fail_timeout=0;
}

server {
    listen [::]:443 ssl http2;
    listen 443 ssl http2;
    server_name superset.corp.com;

    access_log  /var/log/nginx/superset-ssl.access.log logfmt;
    error_log  /var/log/nginx/superset-ssl.error.log;


    include /etc/nginx/includes/default-ssl.conf;

    location / {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Host $http_host;
        # we don't want nginx trying to do something clever with
        # redirects, we set the Host: header above already.
        proxy_redirect off;
        proxy_pass http://superset_app_server;
    }
}

superset.service

[Unit]
Description=Superset Service
After=network.target
Requires=superset.socket

[Service]
Type=notify
ExecStart=uv run gunicorn --worker-connections 100 --timeout 60 --limit-request-line 0 --limit-request-field_size 0 --pythonpath "/home/superset/superset/config" "superset.app:create_app()"
ExecReload=/bin/kill -s HUP $MAINPID
KillMode=mixed
TimeoutStopSec=5
User=superset
Group=superset
WorkingDirectory=/home/superset/superset

[Install]
WantedBy=multi-user.target

and superset.socket

[Unit]
Description=superset socket

[Socket]
ListenStream=/run/superset.sock
# Our service won't need permissions for the socket, since it
# inherits the file descriptor by socket activation
# only the nginx daemon will need access to the socket
SocketUser=www-data


[Install]
WantedBy=sockets.target

This setup worked great with a standard python venv, now with uv it's not working, I suspect the problem to be here : https://github.com/benoitc/gunicorn/blob/master/gunicorn/systemd.py#L38

I don't know what your opinion is on this.

[pajod]

This is normal, applications are supposed to check whether the passed fds are intended "for them", see:
https://github.com/systemd/systemd/blob/104587314ff25a5c35390eeb42308f083e1e0488/src/libsystemd/sd-daemon/sd-daemon.c#L57

If your wrapper does not do this for you after fork, try fixing up your environ["LISTEN_PID"] yourself, in gunicorn.conf.py?

[RemiDesgrange]

Thanks for the answser, I ended up running pre-check in ExecStartPre.