С чем связан «Сбой» сервиса в менеджере systemd?

Question

[chelkaz]

Есть сервис, my.service
Статус показывал все отлично systemctl status my
Пример:

my.service - My queue worker
   Loaded: loaded (/etc/systemd/system/my.service; enabled; vendor preset: disabled)
   Active: active (running) since Wed 2017-04-05 05:41:20 MSK; 2min 34s ago
 Main PID: 7915 (php)
   CGroup: /system.slice/my.service
           └─7915 /usr/local/php/bin/php /www/artisan queue:work --sleep=30 --tries=3

Но он не запускал команду! Я все переворошил на стороне php и был уверен в статусе, раз все работает, то значит запускает. 2 часа логировал php, искал причину, и все сводилось к тому, что никакого запуска команды от my.service не происходит. Я решил сделать systemctl daemon-reload
И О ЧУДО! Все заработало. Но как так?! Почему?! Как же статус?!

Answer 1

[PrAw]

если процесс /usr/local/php/bin/php продолжает оставаться в памяти, но занят чем-то не тем - с точки зрения менеджера он вполне работает.

Ищите в коде демона проблемы, добавляйте логирование, чтобы разобраться в причинах или какой-нить watchdog с внешним контролем, чтобы подпереть костылём

Comments

[chelkaz]

А что Вы имеете ввиду занят чем-то не тем? Например чем он может быть еще занят?
Тут в коде нет по сути и ни чего.

[Unit]
Description=Queue worker
After=nginx.service
After=httpd.service
After=redis-server
After=mysql.service

[Service]
User=www
Group=www
Restart=on-failure
ExecStart=/usr/local/php/bin/php /www/artisan queue:work --sleep=30 --tries=3

[Install]
WantedBy=multi-user.target

[PrAw]

chelkaz: /www/artisan - вот где-то тут что-то в программе на языке php повисло или сам интерпретатор завис, но не упал, делая вид, что живой.

[chelkaz]

Но если я из консоли в ручную запускаю artisan queue:work то начинает работать. Поэтому тут висеть не может.

[PrAw]

chelkaz: это скрипт. Который запускается _новым_ отдельным процессом и никак не зависит от сервиса, который провисел с момента перезапуска пару недель.

Проблема собственно в некотором недопонимании.
1. Если процесс есть, но не отвечает корректно (не выполняет нужную деятельность)
2. Если процесса нет, но менеджер считает, что он есть

Чтобы исключить второй вариант:
ps aux | grep artisan
и смотрим - а есть ли такой процесс в памяти, как "/usr/local/php/bin/php /www/artisan......"

Чтобы исключить первый вариант - проще настроить автоматический перезапуск сервиса раз в ННН дней. Или докопаться до итоговой причины такого странного поведения.

[chelkaz]

PrAw: А как именно смотреть ps aux | grep artisan Если у меня несколько проектов и в каждом свой artisan + Некоторые я запускал из консоли.

www       1486  0.0  0.3 637604 16708 ?        Ss   Apr01   0:00 /usr/local/php/bin/php /data/wwwroot/onesite/www/artisan queue:work --sleep=600 --tries=3
root      4320  0.0  1.3 625944 55664 pts/0    T    04:08   0:00 php artisan queue:listen
root      4338  0.0  1.3 625948 55900 pts/0    T    04:08   0:00 /usr/local/php/bin/php artisan queue:work  --once --queue=default --delay=0 --memory=128 --sleep=3 --tries=0
root      4461  0.0  1.3 625944 55664 pts/0    T    04:12   0:03 php artisan queue:listen
root      7083  0.0  1.3 625980 55884 pts/0    T    05:13   0:00 /usr/local/php/bin/php artisan queue:work  --once --queue=default --delay=0 --memory=128 --sleep=3 --tries=0
root      7580  0.0  1.3 626172 57700 pts/0    T    05:31   0:00 /usr/local/php/bin/php /data/wwwroot/twosite/www/artisan queue:work
www       7915  0.0  1.3 626164 57652 ?        Ss   05:41   0:00 /usr/local/php/bin/php /data/wwwroot/twosite/www/artisan queue:work --sleep=30 --tries=3
root     10935  0.0  0.0 110172   992 pts/0    S+   08:00   0:00 grep --color artisan

[PrAw]

chelkaz: Смотреть по ид процесса - в выдаче

systemctl status my

поле "Main PID:"
В выдаче ps - второй столбец, искать по нему
повторюсь - просто процесс завис, но не упал. Запуском нового экземпляра - старому ничем не поможешь.

[chelkaz]

PrAw: Я вас понял, но не понял как проверить или узнать почему завис, что могло быть этому причиной и как на стороне CentOS можно это проследить, или... - может возможно что, то типа кол бэк функции сделать на сервис? Например если после выполнения сервиса my.service, php не ответило то перезапустить systemctl daemon-reload или как то так...

[PrAw]

chelkaz: у меня поднят сервис мониторинга nagios3, поэтому я не заморачиваясь добавил бы проверку обращением к сервису. Если ответ получен некорректный - отправить оповещение и ребутнуть сервис.

В Вашем случае - если мониторинга готового нет, или ставить или просто в крон добавить перезапуск сервиса.