Discussion:
[uWSGI] uWSGI + systemd = exiting in failed state
Jorge Gallegos
2012-07-29 00:21:22 UTC
Permalink
Hi,

I am using the below unit file to manage uwsgi in fedora (I maintain the
fedora package, and am working on the systemd integration for f18):

[Unit]
Description=uWSGI Emperor Service
After=syslog.target

[Service]
ExecStartPre=/bin/mkdir -p /run/uwsgi
ExecStartPre=/bin/chown uwsgi:uwsgi /run/uwsgi
ExecStart=/usr/sbin/uwsgi --ini /etc/uwsgi.ini
ExecStop=/usr/sbin/uwsgi --stop /run/uwsgi/uwsgi.pid
ExecReload=/usr/sbin/uwsgi --reload /run/uwsgi/uwsgi.pid
Restart=always
Type=notify
StandardError=syslog

[Install]
WantedBy=multi-user.target

Which is based on the one here
http://projects.unbit.it/uwsgi/wiki/SystemdIntegration

The /etc/uwsgi.ini file is this:

[uwsgi]
uid = uwsgi
gid = uwsgi
socket = /run/uwsgi/uwsgi.socket
pidfile = /run/uwsgi/uwsgi.pid
emperor = /etc/uwsgi.d
emperor-tyrant = true

And I am so far getting two issues:

1) stopping/restarting the service throws puts it in "failed state",
like so:

Loaded: loaded (/etc/systemd/system/uwsgi.service; disabled)
Active: failed since Sat, 28 Jul 2012 17:12:08 -0700; 26s ago
Process: 4696 ExecStop=/usr/sbin/uwsgi --stop /run/uwsgi/uwsgi.pid (code=exited, status=0/SUCCESS)
Process: 4677 ExecStart=/usr/sbin/uwsgi --ini /etc/uwsgi.ini (code=exited, status=30)
Process: 4675 ExecStartPre=/bin/chown uwsgi:uwsgi /run/uwsgi (code=exited, status=0/SUCCESS)
Process: 4673 ExecStartPre=/bin/mkdir -p /run/uwsgi (code=exited, status=0/SUCCESS)
Status: "uWSGI is ready"
CGroup: name=systemd:/system/uwsgi.service

The process appears as "failed" even tho I only did a systemctl stop. At first
I thought it was because of the way uwsgi reacts to TERM, and so that's
why I am using the --stop and --reload calls in the systemd unit file,
but that made no difference. Should I use die-on-term instead? am I
missing something?

2) /var/log/messages gets a ton of these log lines:

Jul 28 17:12:07 localhost systemd[1]: uwsgi.service: Got notification
message from PID 4678, but reception only permitted for PID 4677

I assume is because the emperor is polling the location of the configs
(in this case /etc/uwsgi.d) for new config files, but the way it is
interacting with systemd doesn not quite match. I will probably change
this to /var/log/uwsgi.log but wanted to know why this is happening.


Any feedback will be greatly appreciated.

Thanks
--
~kad - Mutt 1.5.21 (2010-09-15)
C Anthony Risinger
2012-07-29 04:45:16 UTC
Permalink
Post by Jorge Gallegos
Hi,
I am using the below unit file to manage uwsgi in fedora (I maintain the
[...]
Post by Jorge Gallegos
1) stopping/restarting the service throws puts it in "failed state",
[...]
Post by Jorge Gallegos
The process appears as "failed" even tho I only did a systemctl stop. At first
I thought it was because of the way uwsgi reacts to TERM, and so that's
why I am using the --stop and --reload calls in the systemd unit file,
but that made no difference. Should I use die-on-term instead? am I
missing something?
the problem here i think is due your your using an outside process to
kill/reload the service, this is neither necessary or ideal.

... remove `ExecStop` and replace with:

KillSignal=SIGINT

... replace `ExecReload` with:

ExecReload=/bin/kill -HUP $MAINPID

... you don't even need pidfiles :-) they have never been reliable anyways.
Post by Jorge Gallegos
Jul 28 17:12:07 localhost systemd[1]: uwsgi.service: Got notification
message from PID 4678, but reception only permitted for PID 4677
I assume is because the emperor is polling the location of the configs
(in this case /etc/uwsgi.d) for new config files, but the way it is
interacting with systemd doesn not quite match. I will probably change
this to /var/log/uwsgi.log but wanted to know why this is happening.
this one is possibly related to my comments above -- i'm not 100% sure
offhand -- might be a bug too, or some other misconfiguration.

... either way, if need be, it can likely be worked around by adding

NotifyAccess=all

... to the `uwsgi.service` file.
--
C Anthony
Jorge Gallegos
2012-07-29 22:45:52 UTC
Permalink
This post might be inappropriate. Click to display it.
Loading...