Я уверен, что кто-то где-то что-то изменил на сервере, но я не могу определить, что произошло. Имейте в виду, что до начала этой недели сервис работал отлично. (ПРИМЕЧАНИЕ: это относится к одному серверу, так как эта же служба работает нормально на 4 других серверах.)
У меня есть следующая служба для запуска PHP-скрипта
start on filesystem and net-device-up IFACE=eth0
respawn
#exec echo OARSUDP ran at `date` >> /var/log/oarsudp.log
script
sudo -u root /usr/bin/php -f /home/src/www-server/services/job_info_parser.php
end script
Если я попытаюсь запустить его, я получаю сообщение -
sudo service oarsudp start
oarsudp start/running, process 2604
Если сразу проверю статус, я получаю -
sudo service oarsudp status
oarsudp stop/waiting
Я добавляю exec строка для отправки комментария к журналу. Работает только тогда, когда script теги и их содержимое закомментированы.
Я запустил строку PHP внутри тега script из командной строки, и она работает отлично, без ошибок.
Я подтвердил правильность разрешений внутри /etc/init/ (корень пользователя, корень группы, права доступа 644).
Я попытался изменить название службы только потому, что прочитал сообщение о некоторых противоречивых именах и цеплялся за соломинку.
Похоже, что служба пытается возродиться, отправляя сообщение журнала в exec несколько раз до того, как сервис умрет.
Я только что нашел журналы Upstart, и они говорят -
«Не удалось открыть входной файл: /home/src/www-server/services/job_info_parser.php».
Я пробовал изменить разрешения, группу и владельца, но ничего не помогло.
Кто-нибудь видел, чтобы служебный скрипт так переставал работать? Если да, то в чем была причина и как ее исправить? Или я полный идиот, создав проблему в скрипте или сервисе?
Я предполагаю, что это длительная задача типа демона; если это одноразовая задача "запустить и остановить", тогда вам понадобится ключевое слово "задача".
1) exec и script, насколько мне известно, исключают друг друга; это два разных способа указать, что запускать для этого задания.
2) Я не вижу причин для sudo; upstart запускается от имени пользователя root, и вы можете использовать setuid / setgid, чтобы изменить пользователя / группу, которую выполняет задание, как если бы оно не должен быть root.
Я подозреваю, что sudo сбивает с толку или скрывает то, что на самом деле происходит; upstart очень внимательно относится к отслеживанию идентификаторов запущенных задач. Видеть http://upstart.ubuntu.com/cookbook/#expect для некоторых кровавых подробностей; на самом деле, посмотрите всю эту страницу для некоторых возможных других подсказок