Home / server / Questions / 211525
Accepted
grucha
Asked: 2010-12-12 00:48:55 +0800 CST

Supervisor not loading new configuration files

  • 772

I have a problem deploying Django app using Gunicorn and Supervisor. While I can make Gunicorn serving my app (by setting proper PYTHONPATH and running apropriate command, the one from supervisord config) I can't make supervisor to run it. It just won't see my app. I don't know how to make sure if the config file is ok.

Here's what supervisorctl says:

# supervisorctl start myapp_live
myapp_live: ERROR (no such process)

I'm running it on Ubuntu 10.04 with following config:

File /home/myapp/live/deploy/supervisord_live.ini:

[program:myapp_live]
command=/usr/local/bin/gunicorn_django --log-file /home/myapp/logs/gunicorn_live.log --log-level info --workers 2 -t 120 -b 127.0.0.1:10000 -p deploy/gunicorn_live.pid webapp/settings_live.py
directory=/home/myapp/live
environment=PYTHONPATH='/home/myapp/live/eco/lib'
user=myapp
autostart=true
autorestart=true

In /etc/supervisor/supervisord.conf, at the end of the file, there is:

[include]
files = /etc/supervisor/conf.d/*.conf

and here's a symlink to my config file:

# ls -la /etc/supervisor/conf.d
lrwxrwxrwx 1 root root   48 Dec  4 18:02 myapp-live.conf -> /home/myapp/live/deploy/supervisord_live.ini

everything looks fine for me but supervisorctl just keep saying myapp_live: ERROR (no such process). Any solution for this?

deployment gunicorn supervisord

12 Answers

  1. The correct answer is that supervisor requires you to re-read and update when you place a new configuration file. Restarting is not the answer, as that will affect other services. Try:

    supervisorctl reread
supervisorctl update
    • 264
  2. Best Answer

    I had the same issue, a 

    sudo service supervisord reload

    did the trick, though I don't know if that is the answer to your question.

    • 44

  3. Make sure your supervisor conf files end in .conf

    Took me a while to figure that one out. Hopefully it helps the next person.

    • 22

  4. Reloading the master supervisor process may work, but it will have unintended side effects if you have more than one process being monitored by supervisor.

    The correct way to do it is to issue supervisorctl reread which causes it to scan configuration files for any changes:

    root@debian:~# supervisorctl reread
gunicorn: changed

    Then, simply reload that app:

    root@debian:~# supervisorctl restart gunicorn
gunicorn: stopped
gunicorn: started
    • 15

  5. I had a similar problem ( myapp_live: ERROR (no such process) ) and it was because my process definition was

    [program: myapp_live]

    when it should have been

    [program:myapp_live]

    While this doesn't address the question that was asked, I was lead here by the Search that Be looking for a solution to my problem, so hopefully other people find it here, too.

    • 7

  6. I encountered this problem using the supervisor package, version 3.0a8-1.1 from Ubuntu Server 12.10. I ended up solving the problem by reading the built-in help:

    $ sudo supervisorctl help restart
restart <name>          Restart a process
restart <gname>:*       Restart all processes in a group
restart <name> <name>   Restart multiple processes or groups
restart all             Restart all processes

    In particular you want to use the syntax:

    sudo supervisorctl restart myapp_live:*

    As the documentation states at http://supervisord.org/configuration.html#programx-section -- "A [program:x] section actually represents a “homogeneous process group” to supervisor (as of 3.0)." So maybe the problem first surfaced in version 3.0.

    PS: I'm new to supervisor; I'm using https://github.com/bdarnell/tornado-production-skeleton/blob/8ad055457646929c0e8f48aaf20d98f054b1787b/production/chat.supervisor as an example of what a minimal configuration should look like.

    • 5

  7. Here is a checklist:

    1. The new config file should be named according to the include pattern configured in /etc/supervisord.conf:

      [include]
files=supervisord.d/*.ini

      As we see in my case, spam.ini would be included, but spam.conf would not.

    2. If you created the new file by copying an old one, make sure to actually change the [program:] line. Because if you are as stupid as having two files for the same program, supervisorctl reread will leave you with this hopeless error message as punishment:

      No config updates to processes

    3. If your file is detected, supervisorctl reread should say something like:

      spam: available

    4. Then, supervisorctl update spam should both start it and make it appear in supervisorctl status.

    • 3

  8. I've found the init.d scripts to be unreliable on a variety of different Ubuntu/Debian versions. The way to do it is this:

    sudo supervisorctl reload
    • 2

  9. I found this solution to be most convenient:

    EDIT: before doing this check your supervisorctl path using which supervisorctl to make sure you are adding right path to sudoers.

    Add this line to sudoers file using visudo (where: myappuser - the user that needs to restart your app, myapp - app name):

    myappuser  ALL=(ALL) NOPASSWD: /usr/bin/supervisorctl restart myapp

    And then simply:

    sudo supervisorctl restart myapp

    You are not tied to distribution's startup scripts and you give quite narrow privileges to user restarting your gunicorn app. Also, you don't need to care about pid. The command will not ask for password so it's suitable for auto-deployment bash/fabric scripts. On the other hand - you have to be aware, that if supervisorctl is vulnerable to some bug causing code execution a malicious user could use this sudo privilege to run code as root (but as far as I know no such bug was discovered for supervisord and it's a big thing to find such vulnerability).

    • 2

  10. Reading the code of supervisorctl.py here: https://github.com/Supervisor/supervisor/blob/master/supervisor/supervisorctl.py

    You can see that supervisorctl update (function do_update) is calling reloadConfig() exactly as supervisorctl reread (function do_reread) does.

    So i think that calling reread is not necessary if you call update after it.

    From the output of git blame it has been like this since at least since july 2009.

    • 2