[Triage] Switching from Gunicorn 23 to 25 breaks Django + k8s workload

[BehnazMoradabadi]

Type

Bug Report

Description

We had a container based on Django + Gunicorn 23 with these readinessProb and strartupProb and it was working fine:

          startupProbe:
            failureThreshold: 3
            httpGet:
              path: /health/liveness/
              port: 8080
              scheme: HTTP
            initialDelaySeconds: 30
            periodSeconds: 10
            successThreshold: 1
            timeoutSeconds: 10
          readinessProbe:
            exec:
              command:
              - wget
              - -O
              - /dev/null
              - http://localhost:8080/health/readiness/
            failureThreshold: 3
            initialDelaySeconds: 10
            periodSeconds: 10
            successThreshold: 1
            timeoutSeconds: 30

after upgrading to gunicorn 25, k8s starts considering the pod unhealthy with

  Warning  Unhealthy  16s    kubelet            Readiness probe failed: command timed out: "wget -O /dev/null http://localhost:8080/health/readiness/" timed out after 30s

Rediness function does nothing except sending an empty response:

    def readiness(self, request):
        return HttpResponse()

I don't see any weird log in the pod. It seems to be working, but it gets restarted constantly.
Can you please help me how to debug this furthur. No spike in the cpu or memory or even data transfer

Steps to Reproduce (for bugs)

No response

Configuration

bind = "[::]:8080"
access_log_format = '%(h)s - %(u)s [%(t)s] "%(r)s" %(s)s %(b)s "%(f)s" "%(a)s"'
accesslog = "-"
disable_redirect_access_to_syslog = True
errorlog = "-"

graceful_timeout = 60

workers = 1
threads = 4
timeout = 60

Logs / Error Output

Warning  Unhealthy  16s    kubelet            Readiness probe failed: command timed out: "wget -O /dev/null http://localhost:8080/health/readiness/" timed out after 30s

Gunicorn Version

gunicorn 25.0.3

Python Version

python:3.12

Worker Class

sync (default)

Operating System

alpine3.19

Additional Context

No response

Checklist

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

[benoitc]

what curl to that endpoint gives you?

[benoitc]

@BehnazMoradabadi I've created #3518 . Right now as a quick workaround you can increase threads from 4 to 16 or increase the number of workers to 2-4. I would definitely increase the number of workers anyway.

[david-gang]

Thanks for the quick workaround. One note — in Kubernetes deployments, the common pattern is workers=1 per pod and scaling horizontally via pod replicas (HPA). Increasing workers inside the pod conflicts with
that model since K8s manages resource limits and scaling at the pod level, not per-worker. For us, increasing threads is the viable workaround. Should workers=1 with a reasonable thread count remain a supported
configuration in v25, or is the fix in #3519 expected to address this regardless of worker count?