Question uWSGI ne commencera pas par systemd sous Ubuntu 16.04


Je suis en train d'effectuer une migration quelque peu pénible de nos serveurs de transfert et de production d'Ubuntu 12.04 à 16.04. Je teste la migration sur la mise en scène et elle fonctionne principalement, à l'exception du fait que uWSGI est lancé sous systemd (auparavant, il fonctionnait correctement sous Upstart). Cela fonctionne sans problème:

uwsgi --ini /etc/uwsgi/my_wsgi.ini

Mais exécuter ce qui suit ne fonctionne pas (uWSGI ne démarre pas, mais ne génère pas d’erreur):

sudo systemctl start uwsgi

J'ai créé le service suivant dans /etc/systemd/system/uwsgi.service:

[Unit]
Description=uWSGI Service

[Service]
ExecStart=/usr/local/bin/uwsgi --ini /etc/uwsgi/my_wsgi.ini
Restart=always
RestartSec=5
KillSignal=SIGQUIT
Type=notify
NotifyAccess=all

[Install]
WantedBy=multi-user.target

et my_wsgi.ini a les caractéristiques suivantes:

[uwsgi]

# Django-related settings
# the base directory (full path)
chdir           = /path/to/project/hidden
# Django's wsgi file
module          = wsgi
# process-related settings
# master
master          = true
# maximum number of worker processes
processes       = 8
# the socket (use the full path to be safe)
socket          = /path/to/socket/hidden
# ... with appropriate permissions - may be needed
chmod-socket    = 666
# clear environment on exit
vacuum          = true
# Mercilessly kill this worker if it takes longer than this time to reload
reload-mercy    = 8
# Reload workers after the specified amount of managed requests (avoid memory leaks)
max-requests    = 5000
# Every request that will take longer than the seconds specified in the harakiri timeout will be dropped and the corresponding worker is thereafter recycled.
harakiri        = 90
# Log everything and make daemon
daemonize       = /var/log/uwsgi/my.log
# use custom settings file
env             = DJANGO_SETTINGS_MODULE=settings.staging
# set pid file for starting/stopping server
pidfile         = /path/to/pid/hidden.pid
# See https://docs.newrelic.com/docs/python/python-agent-and-uwsgi
enable-threads  = true
single-interpreter = true

Fonctionnement systemd-analyze verify uwsgi.service ne renvoie rien et sudo journalctl renvoie ce qui suit:

Starting uWSGI Service...
[uWSGI] getting INI configuration from /etc/uwsgi/my_wsgi.ini
Started uWSGI Service.
uwsgi.service: Service hold-off time over, scheduling restart.
Stopped uWSGI Service.
... (repeats a few times) ....

Je soupçonne que uwsgi.service: Service hold-off time over, scheduling restart. pourrait indiquer le problème, mais je n'ai pas été en mesure de le comprendre.


5
2018-03-24 21:25


origine




Réponses:


le documentation uwsgi indique clairement:

NOTE: NE PAS démoniser l'empereur (ou le maître) à moins de savoir ce que vous faites !!!

Malheureusement, vous avez démonisé l'Empereur sans savoir ce que vous faites. De votre question:

# Log everything and make daemon
daemonize       = /var/log/uwsgi/my.log

Le problème est que uwsgi est compatible avec systemd et que l'unité systemd indique à systemd qu'uwsgi informera systemd lorsque uwsgi est prêt à commencer le traitement des demandes. Par défaut, uwsgi démarre dans ce mode lorsque vous êtes sur un système, sauf si vous lui dites de démoniser. Dans ce cas, uwsgi ne fait pas parler à systemd. C'est pourquoi systemd a attendu un moment et a finalement arrêté d'attendre qu'Uwsgi lui dise qu'il était prêt.

Plutôt que d'wsgi démonisez et connectez-vous directement à un fichier, la documentation suggère de le laisser consigner l'erreur par défaut, ainsi que systemd, de récupérer les journaux et de les consigner. Vous voudrez faire cela si vous souhaitez éventuellement que la journalisation soit envoyée ailleurs, telle qu'une pile ELK. Par exemple:

[Service]
StandardError=syslog

Ou vous pouvez vous connecter directement depuis uwsgi sans démonisation.

logto = /var/log/uwsgi/my.log

3
2018-03-24 23:07



Hm, j'ai le même fichier de configuration uWSGI depuis des années. Je n'ai pas réalisé que les choses avaient changé. - mathew