主管未加载新的配置文件

我在使用Gunicorn和Supervisor部署Django应用程序时遇到问题。虽然我可以让Gunicorn服务我的应用程序（通过设置适当的PYTHONPATH并运行适当的命令，但它来自超级用户配置），但我无法让超级用户运行它。只是看不到我的应用程序。我不知道如何确定配置文件是否正常。

这是supervisorctl所说的：

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

我在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

这是我的配置文件的符号链接：

# 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

一切对我来说都很好，但是主管一直在说myapp_live: ERROR (no such process)。有什么解决办法吗？

我有同样的问题，

sudo service supervisord reload

绝招，尽管我不知道那是否是您问题的答案。

正确的答案是，主管在放置新的配置文件时要求您重新阅读和更新。重新启动不是解决办法，因为这会影响其他服务。尝试：

supervisorctl reread
supervisorctl update

确保您的主管conf文件以.conf结尾

花了我一段时间找出那个。希望它可以帮助下一个人。

重新加载主主管程序可能会起作用，但是如果主管要监视多个进程，则会产生意外的副作用。

正确的方法是发出supervisorctl reread该错误，导致它扫描配置文件以进行任何更改：

root@debian:~# supervisorctl reread
gunicorn: changed

然后，只需重新加载该应用程序即可：

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

我使用Ubuntu Server 12.10的管理程序包3.0a8-1.1版遇到此问题。我最终通过阅读内置帮助解决了这个问题：

$ 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：我是主管的新手。我使用https://github.com/bdarnell/tornado-production-skeleton/blob/8ad055457646929c0e8f48aaf20d98f054b1787b/production/chat.supervisor作为最小配置外观的示例。

我有一个类似的问题（myapp_live: ERROR (no such process)），这是因为我的流程定义是

[program: myapp_live]

应该什么时候

[program:myapp_live]

虽然这不能解决所提出的问题，但在这里由搜索引导我正在寻找要解决我的问题的方法，因此希望其他人也可以在这里找到它。

我发现此解决方案最方便：

编辑：在执行此操作之前，请检查您的supervisorctl路径which supervisorctl，以确保您向sudoers添加了正确的路径。

使用以下命令将此行添加到sudoers文件中visudo：（其中：myappuser-需要重新启动您的应用的用户，myapp-应用名称）：

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

然后简单地：

sudo supervisorctl restart myapp

您不受发行版启动脚本的束缚，并且为用户重新启动您的gunicorn应用程序提供了相当狭窄的特权。另外，您无需关心pid。该命令不会要求输入密码，因此适用于自动部署bash / fabric脚本。另一方面-您必须知道，如果supervisorctl容易受到导致代码执行的某些错误的影响，则恶意用户可以使用此sudo特权以root身份运行代码（但据我所知，没有为supervisor和找到这样的漏洞是一件大事）。

在此处阅读supervisorctl.py的代码：https : //github.com/Supervisor/supervisor/blob/master/supervisor/supervisorctl.py

您可以看到，supervisorctl更新（函数do_update）正在完全按照supervisorctl重读（函数do_reread）的方式调用reloadConfig（）。

因此，我认为如果您在更新后调用更新，则不需要重新读取。

从git blame的输出来看，至少从2009年7月以来一直是这样。

这是一个清单：

1. 新的配置文件应根据/etc/supervisord.conf中配置的包含模式来命名：

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

   正如我们在我的案例中看到的那样，将包含spam.ini，但不会包含spam.conf。

2. 如果通过复制旧文件创建了新文件，请确保实际更改该[program:]行。因为如果您像在同一个程序中拥有两个文件一样愚蠢，那么您supervisorctl reread将得到以下毫无希望的错误消息作为惩罚：

   No config updates to processes
   

3. 如果检测到您的文件，supervisorctl reread应说出类似以下内容：

   spam: available
   

4. 然后，supervisorctl update spam应同时启动它并使它出现在中supervisorctl status。

我发现init.d脚本在各种不同的Ubuntu / Debian版本上都不可靠。方法是这样的：

sudo supervisorctl reload

注意符号链接，并在Supervisor上包含文件。它将允许任何对/home/myapp/live/deploy/supervisord_live.ini具有w特权的人更改ini文件并启动任何恶意代码。该ini文件应位于主管的conf目录中或该目录下的任何子目录中。

我已经用yum install安装了supervisrod，后者安装了v2。*版本的supervisor。Supervisor仅支持版本3的外部包含。必须使用easy_install来安装supervisor v3。