"sudo service uwsgi restart" returns [fail] however uwsgi logs show processes have been created and python app is running

14,655

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.

Share:
14,655
Admin
Author by

Admin

Updated on November 26, 2022

Comments

  • Admin
    Admin over 1 year

    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?

    • Admin
      Admin over 8 years
      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.
    • Admin
      Admin over 8 years
      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.
    • Admin
      Admin about 4 years
      Just a guess: by default 4 processes with name "uwsgi" are created, and service script can not choose from them by name. Earlier the main process of uwsgi was named uwsgi-emperor but now they are confused.
  • Admin
    Admin about 10 years
    Had the same problem, renaming pidfile worked. Link to documentation, for reference: uwsgi-docs.readthedocs.org/en/latest/Options.html#pidfile2
  • Admin
    Admin about 4 years
    does not fix... all priveleges are done, but service can not choose from multiple instances