6

I'm running a local vagrant VM, Ubuntu 13.10 with nginx reverse proxying to uwsgi.

Running

sudo /etc/init.d/nginx status 

returns

* nginx is running

However running

sudo /etc/init.d/uwsgi status 

returns

* which one?

If I take a look at the log file for the wsgi app I can see that uwsgi is running, worker processes have been created etc... so is there a hidden instance of uwsgi running somewhere that's confusing the service restart command?

I installed uwsgi using:

apt-get install uwsgi

Here's the app.ini file:

[uwsgi]
plugin = python
socket  = /run/uwsgi/app/myapp/socket
chdir = /var/www/myapp
module = project.wsgi:application
pidfile = /tmp/myapp-master.pid
master = True
daemonize = /var/log/uwsgi/myapp.log

Any ideas?

migrated from stackoverflow.com Mar 26 '14 at 0:10

This question came from our site for professional and enthusiast programmers.

  • Same issue Ubuntu 14.04 (Trusty) with 1.9.17.1-debian. This has to be a bug, but I don't know if it belongs to the people behind the Ubuntu repository, or to uwsgi. – Mads Skjern Jul 9 '15 at 16:20
  • In any case, I just install with PIP instead. PIP does not install it as a service, so I create /etc/init/uwsgi.conf myself. The startup files are much much easier to read and understand (and write) which is another bonus. – Mads Skjern Jul 9 '15 at 16:22
6

Changing the pidfile option to pidfile2 seems to fix this issue.

pidfile2 = /tmp/myapp-master.pid

Interestingly the service uwsgi stop returns [OK] but the service uwsgi start returns [fail]

So I'm assuming the error happens when a non privileged user (i.e. www-data) is trying to write to the pidfile which has been created by a privileged user (e.g. root).

pidfile2 will create the pidfile after privileges drop - so www-data can happily write to it.

If someone else can shed light on whether this is the case that would be great.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy