私は、ステージングサーバーと運用サーバーの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.
が問題を指摘している可能性がありますが、それを理解することができませんでした。
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