web-dev-qa-db-ja.com

uWSGIがUbuntu 16.04のsystemdで起動しない

私は、ステージングサーバーと運用サーバーのUbuntu 12.04から16.04への移行がやや苦しい作業を行っています。私はステージングで移行をテストしていますが、systemdの下でuWSGIを開始することを除いて、それはほとんど機能しています(以前はUpstartで正常に機能していました)。これは問題なく動作します:

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

ただし、以下を実行しても機能しません(uWSGIは起動しませんが、エラーは発生しません)。

Sudo systemctl start uwsgi

/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

my_wsgi.iniには以下が含まれます。

[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

ランニング systemd-analyze verify uwsgi.serviceは何も返さず、Sudo journalctlは以下を返します。

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) ....

uwsgi.service: Service hold-off time over, scheduling restart.が問題を指摘している可能性がありますが、それを理解することができませんでした。

6
mathew

wsgiのドキュメント には次のように明記されています。

注:何をしているのかわからない限り、皇帝(またはマスター)をデーモン化しないでください。

残念ながら、あなたは何をしているか知らずに皇帝をデーモン化しました。あなたの質問から:

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

問題は、uwsgiがsystemdに対応しており、systemdユニットがsystemdに、uwsgiが要求の処理を開始する準備ができたときにuwsgiがsystemdに通知することを通知することです。デフォルトでは、systemdシステムの場合、uwsgiはこのモードで起動し、unlessしてデーモン化するように指示します。その場合、uwsgiはsystemdと通信しません。これがsystemdがしばらく待機し、最後にuwsgiが準備が整ったことをsystemdに通知するのを待つのをやめた理由です。

Uwsgiをデーモン化してファイルに直接ログを記録させるのではなく、ドキュメントでは、デフォルトの標準エラーにログを記録させ、systemdがログを取得してログに記録することを推奨しています。 ELKスタックなどの他の場所にログを送信する場合は、これを行う必要があります。例えば:

[Service]
StandardError=syslog

または、デーモン化せずにuwsgiから直接ログを記録することもできます。

logto = /var/log/uwsgi/my.log
5
Michael Hampton