Starting uWSGI service fails silently

Question

I'm having a problem which is driving me nuts. I'm trying to create an Ubuntu 15.04 Upstart job, which would start uWSGI server (uWSGI version 2.0.7-debian) running a Django application.

I've configured the service as a follows and try to start the job by issuing command $ sudo service uwsgi start. There is no output in log files, no socket file created and no error.

# file: /etc/init/uwsgi.conf

description "uWSGI server"

start on runlevel [2345]
stop on runlevel [!2345]

exec /usr/bin/uwsgi --ini /srv/configs/uwsgi.ini

service uwsgi status says

● uwsgi.service - LSB: Start/stop uWSGI server instance(s)
Loaded: loaded (/etc/init.d/uwsgi)
Active: active (exited) since Tue 2015-05-05 09:40:08 EEST; 1s ago
  Docs: man:systemd-sysv-generator(8)
Process: 21405 ExecStop=/etc/init.d/uwsgi stop (code=exited, status=0/SUCCESS)
Process: 21460 ExecStart=/etc/init.d/uwsgi start (code=exited, status=0/SUCCESS)

May 05 09:40:08 web-2 systemd[1]: Starting LSB: Start/stop uWSGI server instance(s)...
May 05 09:40:08 web-2 uwsgi[21460]: * Starting app server(s) uwsgi
May 05 09:40:08 web-2 uwsgi[21460]: ...done.
May 05 09:40:08 web-2 systemd[1]: Started LSB: Start/stop uWSGI server instance(s).

The uWSGI app is configured as

[uwsgi]

uid = www-data
gid = www-data
socket = /srv/sockets/uwsgi.sock
chmod-socket = 666
master = true
processes = 4
enable-threads = true
plugins = python
chdir = /srv/sites/current
module = wsgi:application
virtualenv = /srv/environments/current
logto = /srv/logs/uwsgi.log
logfile-chown = true
touch-reload = /srv/sites/current/wsgi.py

The service starts fine and everything works ok if the service is started directly, e.g. by issuing command: sudo -u www-data /usr/bin/uwsgi --ini /srv/configs/uwsgi.ini

For the socket dir and log files directories I've set the most relaxed permissions.

So, I'm at a loss. What to do next?

Dime

From what I've seen about systemd in Ubuntu 15.04 it may not log to any /var/log files by default. And it may store it's 'unit' configuration files somewhere besides /etc/init: I am seeing /lib/systemd/system in the documentation and your status output shows /etc/init.d. So maybe it's using a different service configuration file that puts the socket file in a location you are not looking at. I say this because your status output indicates that systemd thinks uwsgi is already running. You could look for the process with ps auxww|wsgi. – Altarpiece

ps aux | grep wsgi shows just the grep line, so the processes aren't running. Additionally, I tried to create a uwsgi.service file to /lib/systemd/system with these instructions, uwsgi-docs.readthedocs.org/en/latest/Systemd.html but sudo systemctl status uwsgi.service reports the same thing than service uwsgi status. – Dime

I'm glad I provided some kind of help. Should you post your own answer to the question? – Altarpiece

After seeing your comment, I solved the problem in 15 mins. I would say your help was critical. – Dime

Answer 1

Thanks to nmgeeks comment, I started looking at other places where uWSGI is configured.

While trying to move everything our own app related under /srv I deleted /run/uwsgi directory, where uWSGI is trying to create a PID file.

You can find the reference at /usr/share/uwsgi/conf/default.ini.

Too bad uWSGI doesn't produce any error in this situation, which left me frustrated for a day.

Dime

Answer 2

I just want to put some additional details. In my case I didn't delete anything, but, for some reasons, systemd was not able to create /run/uwsgi directory. So, I did echo "/run/uwsgi 0755 www-data www-data -" > /etc/tmpfiles.d/uwsgi.conf. After that I restarted my VM (I didn't find a way to apply this changes without restarting) and uwsgi started to work!

Yes, it's too bad that uWSGI doesn't produce any error in this situation.

Frenzied