[BUG]: ddtrace block uwsgi socket

[EloiS-RE]

Tracer Version(s)

3.14.1

Python Version(s)

Python 3.11.2

Pip Version(s)

23.2.1

Bug Report

When using ddtrace with uwsgi for python application backend application running with Django, we got an issue during the launching of the application. The uwsgi sockets seem to not be able to process any http request leading to a filling of the queue.

With the following versions, the system is working and the issue is not happening:

• ddtrace==3.12.2
• uwsgi==2.0.29

Reproduction Code

No response

Error Logs

*** uWSGI listen queue of socket "127.0.0.1:33407" (fd: 3) full !!! (101/100) ***

Libraries in Use

ddtrace==3.14.1
Django==5.0.12
drf-spectacular==0.27.2
uWSGI==2.0.29
uwsgi-readiness-check==0.2.0

more on request

Operating System

Linux 4.18.0 GNU/Linux

[P403n1x87]

@EloiS-RE thanks for reporting this.

more on request

is gevent also in the mix? Could you share the full uwsgi command line options that you're using to start your service. Our docs have some details about how to start uwsgi in a way that is compatible with ddtrace.

[EloiS-RE]

We don't have gevent. The only diff there is with your doc is that we dont use "--skip-atexit" in the command compared to your doc.

/opt/venv/bin/uwsgi \
  --http :8080 \
  --chdir ${XXXX} \
  --static-map /static=${XXXX} \
  --add-header 'Strict-Transport-Security: max-age=31536000; includeSubDomains' \
  --add-header 'X-Frame-Options: DENY' \
  --add-header 'X-Content-Type-Options: nosniff' \
  --add-header 'X-XSS-Protection: 1; mode=block' \
  --die-on-term \
  --processes ${XXXX} \
  --queue ${XXXX} \
  --master \
  --wsgi-file ${XXXX}/wsgi.py \
  --pidfile /uwsgi/uwsgi_master.pid \
  --master-fifo /uwsgi/uwsgi_master.fifo \
  --stats /uwsgi/uwsgi_stats.sock \
  --buffer-size ${XXXX} \
  --enable-threads \
  --lazy-apps \
  --import ddtrace.bootstrap.sitecustomize ${XXXX}

[P403n1x87]

Thanks for sharing. The --skip-atexit is needed to avoid a potential crash on shutdown with older versions of uWSGI, so that should not be a factor in the socket issue. We'll have a look to see if we can reproduce the issue on our end and get back to you as soon as we find something to share.