108

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?

Improve this question
1
  • I was scratching my head with the same problem; my configuration files weren't being loaded when I ran reread or update. It turned out I had saved my config files as foo.conf.py instead of foo.conf so they weren't being identified. Commented Sep 11, 2014 at 15:49

14 Answers 14

Reset to default
52

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.

Improve this answer
8
  • 2
    I stopped and then started supervisor some time ago and it worked. Don't know if reload would work (as I heart restart doesn't) but I guess it could Commented Dec 21, 2010 at 8:41
  • 1
    I did it too and it got worked. I wonder why /etc/init.d/supervisor restart doesn't work when manual stop and start do. Commented Feb 29, 2012 at 12:33
  • 2
    Worked for me, though the service didn't work so I just ran ps aux | grep supervisor and then sudo kill -HUP pid Commented Aug 13, 2012 at 3:04
  • 3
    This is dangerous as it will restart the whole of the supervisor daemon. Commented Feb 17, 2013 at 20:04
  • 7
    supervisorctl reread can fix this aswell without restarting the service. Commented Aug 27, 2013 at 13:20
292

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
Improve this answer
6
  • 19
    This should be the correct answer. "supervisor reread" alone is not enough. Commented Oct 21, 2013 at 16:04
  • 4
    +1 This is a better answer because it doesn't rely on Process Managers. Commented Jul 30, 2014 at 15:29
  • 13
    "supervisorctl reread" alone is not enough, but wouldn't "supervisorctl update" suffice? According to the documentation "update" does a reread followed by a restart of any programs whose configuration was modified by the reread. Commented Sep 8, 2014 at 22:03
  • It work for me. I have done restart afterward. Commented Aug 22, 2019 at 11:34
  • 1
    Will this also work if I changed something in [inet_http_server]? Commented Mar 4, 2020 at 16:58
27

Make sure your supervisor conf files end in .conf

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

Improve this answer
5
  • 1
    Wasted an hour on the same issue - can't believe it was this simple. Commented May 5, 2016 at 17:22
  • 1
    Thanks for listing this answer. For the life of me, I could not figure this one out. Commented Jun 2, 2016 at 14:54
  • 1
    Lol, I've named my config file <my-config>.py. I'm tired :D Thanks ! Commented May 5, 2021 at 18:07
  • Amazing response. Commented Dec 20, 2022 at 20:24
  • this answer has helped me.. 10 years since Commented Jul 3, 2024 at 1:59
15

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
Improve this answer
2
  • 1
    This is the best solution if you only want to read a changed/new config file and leave the rest of the running processes untouched. Supervisorctl will show the new app is avail. Add it to the (re)startable processes by issueing supervisorctl update. See also Mark's answer serverfault.com/a/479754/125887 Commented Jun 13, 2013 at 7:23
  • 5
    This was not enough for me. supervisorctl update was necessary. Commented Jan 22, 2016 at 15:39
8

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.

Improve this answer
1
  • Same here! I had left it as [program] only, following the docs, but making it [program:redis] made it work for me. Things sure get weird at times! Commented Jul 16, 2016 at 7:08
5

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.

Improve this answer
3

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. Otherwise, supervisorctl reread will not tell you so:

    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.

Improve this answer
2

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
Improve this answer
1
  • This is not the right way to do it although it will work in many circumstances. @burhan-khalid answer is the right one, and provides an explanation for it. Commented Apr 26, 2013 at 18:26
2

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).

Improve this answer
2

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.

Improve this answer
1

I had installed supervisrod with yum install, which installed supervisor of version v2.*. Supervisor supports external includes only from version 3. Had to use easy_install instead, to install supervisor v3.

Improve this answer
1
  • 1
    This was also my issue, it will probably occur on all Centos 6.5 or less installs. Commented Feb 18, 2015 at 0:42
1

Be careful with symlinks and include files on Supervisor.

It would allow any person with w privilege on /home/myapp/live/deploy/supervisord_live.ini to change the ini file and start any malicious code.

This ini file should be inside your supervisor's conf directory or in any sub dir under it.

Improve this answer
0

One more thing I had to do is change the file permissions of the script by running the following command:

chmod +x /etc/init.d/your_script

This digital ocean tutorial can be of great help to help you figure out some issues.

Improve this answer
0

This will do:

sudo supervisorctl reread && sudo supervisorctl update && sudo supervisorctl restart all
Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.