我使用Gunicorn和Supervisor部署Django应用程序时遇到问题。 虽然我可以让Gunicorn为我的应用程序服务（通过设置适当的PYTHONPATH并运行适当的命令，来自supervisord config的那个命令），我不能让主pipe运行它。 它只是不会看到我的应用程序。 我不知道如何确定configuration文件是否正常。
以下是主pipe说：
# supervisorctl start myapp_live myapp_live: ERROR (no such process) 我使用以下configuration在Ubuntu 10.04上运行它：
文件/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
在/etc/supervisor/supervisord.conf中，在文件末尾有：
[include] files = /etc/supervisor/conf.d/*.conf
这里是我的configuration文件的符号链接：
# 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
一切看起来都适合我，但supervisorctl只是说myapp_live: ERROR (no such process) 。 任何解决scheme？
我有同样的问题，一个
sudo service supervisord reload
做的伎俩，但我不知道这是否是你的问题的答案。
正确的答案是，当您放置一个新的configuration文件时，主pipe要求您重新读取和更新。 重新启动不是答案，因为这将影响其他服务。 尝试：
supervisorctl reread supervisorctl update
重新加载主pipe主pipe进程可能会起作用，但是如果主pipe监视了多个进程，将会产生意想不到的副作用。
正确的方法是发出supervisorctl reread ，导致它扫描configuration文件的任何更改：
root@debian:~# supervisorctl reread gunicorn: changed
然后，只需重新加载该应用程序：
root@debian:~# supervisorctl restart gunicorn gunicorn: stopped gunicorn: started
确保您的主pipeconf文件以.conf结尾
花了我一会儿来弄清楚那一个。 希望它有助于下一个人。
我有一个类似的问题（ myapp_live: ERROR (no such process) ），这是因为我的stream程定义是
[program: myapp_live]
当它应该是
[program:myapp_live]
虽然这并没有解决被问到的问题，但我在search引导下，寻找解决scheme来解决我的问题，希望其他人也能在这里find答案。
我使用Ubuntu Server 12.10的3.0a8-1.1版本的Supervisor软件包，遇到了这个问题。 我最终通过阅读内置的帮助来解决问题：
$ 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
特别是你想要使用的语法：
sudo supervisorctl restart myapp_live:*
正如文档在http://supervisord.org/configuration.html#programx-section所述 – “一个[program：x]部分实际上代表了一个”同质过程组“（从3.0开始）。” 所以也许这个问题在3.0版本中首先出现。
PS：我是新来的主pipe; 我使用https://github.com/bdarnell/tornado-production-skeleton/blob/8ad055457646929c0e8f48aaf20d98f054b1787b/production/chat.supervisor作为最小configuration应该是什么样子的例子。
我发现这个解决scheme是最方便的：
编辑：在这之前检查你的supervisorctlpath使用which supervisorctl ，以确保你正在为sudoers添加正确的path。
使用visudo将此行添加到sudoers文件（其中： myappuser – 需要重新启动应用程序的用户， myapp – 应用程序名称）：
myappuser ALL=(ALL) NOPASSWD: /usr/bin/supervisorctl restart myapp
然后简单地说：
sudo supervisorctl restart myapp
你没有绑定到发行版的启动脚本，你给用户重新启动你的gunicorn应用程序相当狭窄的特权。 另外，你不需要关心PID。 该命令不会要求input密码，因此适用于自动部署bash /结构脚本。 另一方面，你必须知道，如果supervisorctl容易受到某些导致代码执行的bug的攻击，那么恶意用户可以使用这个sudo权限来以root身份运行代码（但据我所知，没有发现supervisord和find这样的漏洞是件大事）。
我发现init.d脚本在各种不同的Ubuntu / Debian版本上是不可靠的。 做到这一点的方法是这样的：
sudo supervisorctl reload
在Supervisor上注意符号链接和包含文件。 这将允许任何具有/home/myapp/live/deploy/supervisord_live.ini权限的人更改ini文件并启动任何恶意代码。 这个ini文件应该在你的主pipe的conf目录里，或者在它的任何子目录下。
在这里阅读supervisorctl.py的代码： https ： //github.com/Supervisor/supervisor/blob/master/supervisor/supervisorctl.py
你可以看到supervisorctl更新（函数do_update）正像supervisorctl reread（函数do_reread）那样调用reloadConfig（）。
所以我认为，如果你打电话更新之后，那么调用重读就没有必要了。
从git blame的输出来看，至less从2009年7月起就是这样了。
我安装了yum install的supervisrod，它安装了版本v2。*的主pipe。 Supervisor仅支持从版本3开始的外部包含。不得不使用easy_install来安装Supervisor v3。
这是一个清单：
新的configuration文件应该根据在/etc/supervisord.conf中configuration的包含模式命名：
[include] files=supervisord.d/*.ini
正如我们看到的，spam.ini将被包括在内，但spam.conf不会。
如果您通过复制旧文件来创build新文件，请确保实际更改[program:]行。 如果你对同一个程序有两个文件一样愚蠢， supervisorctl reread会给你带来这个绝望的错误信息：
No config updates to processes
如果你的文件被检测到， supervisorctl reread应该是这样的：
spam: available
然后， supervisorctl update spam应该都启动它，并使其显示在supervisorctl status 。