Qual é a melhor maneira de o uwsgi criar uma pasta '/ run / uwsgi' na reinicialização?

Question

Eu configurei um projeto do Django para rodar com o uwsgi e nginx e está tudo rodando como esperado, exceto que quando eu reiniciar o uwsgi não irá rodar corretamente até que a pasta / run / seja recriada no fs. / run é mapeado para 'tmpfs', então ele precisa ser recriado a cada inicialização.

Eu tenho um arquivo de serviço systemd que eu criei para o 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

E o arquivo /etc/uwsgi.ini tem esta aparência:

[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

Qual é a maneira recomendada para a pasta /run/uwsgi ser recriada em cada inicialização?

    

Answer 1

A maneira como acabei resolvendo esse problema foi usar as distribuições mais recentes. O Fedora 20 e o yum install uwsgi construíram um ambiente onde todos esses detalhes foram tratados automaticamente para mim, enquanto eu estava tentando falsificar isso em um sistema Fedora17 onde ele não estava disponível nos repositórios do yum.

A maneira como o Fedora 20 resolve isso é ter isso em sua unidade de serviço uwsgi:

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

    

Answer 2

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

E do 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.

Em outras palavras, ao usar tmpfiles.d para este "works", a maneira oficialmente recomendada é adicionar

RuntimeDirectory=uwsgi

para a seção [Service] do seu arquivo de unidade.

Isso tem a vantagem de ser mais breve, garante que é criado com a propriedade correta de usuário / grupo e limpa o diretório quando o daemon é interrompido.

    

Answer 3

Você precisa criar um arquivo de configuração em /etc/tmpfiles.d/ , definindo que esse diretório deve ser criado pelo systemd durante a inicialização / inicialização.

Exemplo

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

Defina com qualquer propriedade / permissão que julgue apropriada à sua situação.

OBSERVAÇÃO: Se você usar a configuração que eu forneci acima, provavelmente você vai querer adicionar o grupo uwsgi ao usuário do Nginx nginx :

$ sudo usermod -a nginx -G uwsgi

Referências

• Adicionando o Emperor ao systemd
• O Emperor do uWSGI - implantação de vários aplicativos

Answer 4

O comando Multiple ExecStartPre nem sempre é executado na mesma ordem em que estão listados no arquivo .service.

O que funciona é combinar todos os comandos em uma única chamada sh, assim:

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