mjhjmtu

I have set up a Django project to run with uwsgi and nginx and it's all running as expected, except that when I reboot uwsgi will not launch correctly until the /run/ folder is recreated on the fs. /run is mapped to 'tmpfs' so it needs to be recreated at each boot.

I have a systemd service file that I created for uwsgi:

[Unit]
Description=uWSGI Module
After=syslog.target

[Service]
ExecStart=/usr/bin/uwsgi --ini /etc/uwsgi.ini
Restart=always
KillSignal=SIGQUIT
Type=notify
StandardError=syslog
NotifyAccess=main

[Install]
WantedBy=multi-user.target

And the /etc/uwsgi.ini file looks like this:

[uwsgi]
uid = uwsgi
gid = uwsgi
pidfile = /run/uwsgi/uwsgi.pid
stats = /run/uwsgi/stats.sock
socket = /run/uwsgi/uwsgi.sock
master = true
processes = 1
chdir = /path/to/our/django/app
module = icscada
max-requests = 100
daemonize = /var/log/uwsgi.log

What is the recommended way for the /run/uwsgi folder to be recreated at each boot?

From tmpfiles.d(5):

System daemons frequently require private runtime directories below /run to place communication sockets and similar in. For these, consider declaring them in their unit files using RuntimeDirectory= (see systemd.exec(5) for details), if this is feasible.

And from systemd.exec(5):

RuntimeDirectory=, RuntimeDirectoryMode=

Takes a list of directory names. If set, one or more directories by the specified names will be created below /run (for system services) or below $XDG_RUNTIME_DIR (for user services) when the unit is started, and removed when the unit is stopped. The directories will have the access mode specified in RuntimeDirectoryMode=, and will be owned by the user and group specified in User= and Group=. Use this to manage one or more runtime directories of the unit and bind their lifetime to the daemon runtime.

In other words, while using tmpfiles.d for this "works", the officially recommended way is to add

RuntimeDirectory=uwsgi

to the [Service] section of your unit file.

This has the advantage that it is briefer, guarantees that it's created with the correct user/group ownership, and cleans up the directory when the daemon is stopped.

You need to create a configuration file under /etc/tmpfiles.d/ defining that this directory should be created by systemd during boot/startup.

Example

$ more /etc/tmpfiles.d/uwsgi.conf 
D /run/uwsgi 0770 uwsgi uwsgi -

Set it with whatever ownership/permissions you deem are appropriate for your situation.

NOTE: If you use the setup I provided above then you'll likely want to add the group uwsgi to Nginx's user nginx:

$ sudo usermod -a nginx -G uwsgi

References

• Adding the Emperor to systemd


• The uWSGI Emperor – multi-app deployment

The way I eventually solved this problem was to use the latest distributions. Fedora 20 and yum install uwsgi built an environment where all of these details were handled automatically for me, while I was previously trying to fudge this onto a Fedora17 system where it wasn't available in the yum repositories.

The way Fedora 20 solves this is by having this in its uwsgi service unit:

ExecStartPre=/bin/mkdir -p /run/uwsgi 
ExecStartPre=/bin/chown uwsgi:uwsgi /run/uwsgi

Multiple ExecStartPre's command are not always executed in the same order as they are listed in the .service file.

What works is to combine all commands into a single sh invocation, like this:

ExecStartPre=/bin/sh -c 'mkdir -p /run/uwsgi ; chown uwsgi:uwsgi /run/uwsgi'

The uwsgi package I was installing—the default one on CentOS 7—already included the correct /usr/lib/tmpfiles.d/uwsgi.conf file. But the directory was still not there. A reboot probably would have caused it to be created when systemd-tmpfiles started up fresh, but in my case—

I needed to run

systemd-tmpfiles --create

after installing the package in order to create the directory right away.