uWSGI is a new-style daemon for systemd.
It can notify status change and readyness.
When uWSGI detects it is running under systemd, the notification system is enabled.
Adding the Emperor to systemd¶
The best approach to integrate uWSGI apps with your init system is using the Emperor.
Your init system will talk only with the Emperor that will rule all of the apps itself.
Create a systemd service file (you can save it as /etc/systemd/system/emperor.uwsgi.service)
[Unit] Description=uWSGI Emperor After=syslog.target [Service] ExecStart=/root/uwsgi/uwsgi --ini /etc/uwsgi/emperor.ini Restart=always KillSignal=SIGQUIT Type=notify StandardError=syslog NotifyAccess=all [Install] WantedBy=multi-user.target
Then run it
systemctl start emperor.uwsgi.service
And check its status.
systemctl status emperor.uwsgi.service
You will see the Emperor reporting the number of governed vassals to systemd (and to you).
emperor.uwsgi.service - uWSGI Emperor Loaded: loaded (/etc/systemd/system/emperor.uwsgi.service) Active: active (running) since Tue, 17 May 2011 08:51:31 +0200; 5s ago Main PID: 30567 (uwsgi) Status: "The Emperor is governing 1 vassals" CGroup: name=systemd:/system/emperor.uwsgi.service ├ 30567 /root/uwsgi/uwsgi --ini /etc/uwsgi/emperor.ini ├ 30568 /root/uwsgi/uwsgi --ini werkzeug.ini └ 30569 /root/uwsgi/uwsgi --ini werkzeug.ini
You can stop the Emperor (and all the apps it governs) with
systemctl stop emperor.uwsgi.service
emperor.ini could look like this (www-data is just an anonymous user)
NOTE: DO NOT daemonize the Emperor (or the master) unless you know what you are doing!!!
[uwsgi] emperor = /etc/uwsgi/vassals uid = www-data gid = www-data
If you want to allow each vassal to run under different privileges, remove the
gid options from the emperor configuration (and please read the Emperor docs!)
Using the previous service file all of the Emperor messages go to the syslog. You can avoid it by removing the
If you do that, be sure to set a
--logto option in your Emperor configuration, otherwise all of your logs will be lost!
Putting sockets in /run/¶
On a modern system, /run/ is mounted as a tmpfs and is the right place to put sockets and pidfiles into. You can have systemd create a uwsgi directory to put them into by creating a systemd-tmpfiles configuration file (you can save it as /etc/tmpfiles.d/emperor.uwsgi.conf):
d /run/uwsgi 0755 www-data www-data -
Starting from uWSGI 0.9.8.3 socket activation is available. You can setup systemd to spawn uWSGI instances only after the first socket connection.
[Unit] Description=Socket for uWSGI Emperor [Socket] # Change this to your uwsgi application port or unix socket location ListenStream=/tmp/uwsgid.sock [Install] WantedBy=sockets.target
Then disable the service and enable the socket unit.
# systemctl disable emperor.uwsgi.service # systemctl enable emperor.uwsgi.socket