У меня есть довольно основная конфигурация супервизора:
[program:drape]
process_name=%(program_name)s_%(process_num)02d
command=python /home/ubuntu/drape/workers/drape.py
numprocs=1
autostart=true
autorestart=true
nocleanup=true
stdout_logfile=/home/ubuntu/supervisord.out.log
stdout_logfile_maxbytes=32MB
stderr_logfile=/home/ubuntu/supervisord.err.log
stderr_logfile_maxbytes=32MB
startsecs=180
Я не думаю, что эта конфигурация на самом деле имеет значение, но отправляющий так или иначе. Я использую супервизор запаса глобальная конфигурация. Я установил супервизор с помощью стандарта sudo apt-get -y install supervisor
... и только быть уверенным:
$ sudo apt-get -y install supervisor
Reading package lists... Done
Building dependency tree
Reading state information... Done
supervisor is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 69 not upgraded.
Однако, когда я пытаюсь запустить супервизор, я получаю абсолютно тихий отказ:
ubuntu@...:~$ sudo service supervisor start
ubuntu@...:~$
Нет ничего в журналах (Моя глобальная конфигурация имеет logfile=/var/log/supervisor/supervisord.log
) и нет ничего в "журналах программы" ни одного (logfile=/var/log/supervisor/supervisord.log.<stream>.log
).
У меня есть подобный процесс настройки для других серверов, которые выполняют рубиновых демонов так для закапывания немного далее, я даже создание очень простого рубинового сценария и сделанный chmod 777
вещь, таким образом, нет никаких проблем разрешения:
$ cat test.rb
while 1
puts "hi"
sleep 1
end
$ ruby test.rb
hi
hi
hi
...
Моим вопросом является больше..., "где я должен посмотреть" вопрос. Если супервизор ничего не регистрирует единственное другое место, я могу думать к виду, системный журнал, который не указывает ни на что сумасшедшее мне.
Молчаливый сбой связан с отказом этой строки:
DAEMON=/usr/bin/supervisord
test -x $DAEMON || exit 0
в сценарии supervisor init. Похоже, что по каким-то причинам супервизор был установлен в /usr/local/bin/
на этой машине. Супер раздражает, что ничего не напечатано...
Просто совет для тех, кто может с этим бороться, попробуйте запустить демон напрямую
/usr/bin/supervisord
, и вы должны увидеть ошибки , останавливающие супервизор от бега. Сценарий инициализации супервизора бесполезен для поиска ошибок конфигурации.