Systemd сервис/служба останавливается по непонятной причине. Почему?

Question

[ALLIGATOR]

Два раза за год была ситуация, что останавливался сервис systemd по непонятной причине и не запускался обратно автоматически
Сервис - вебсайт на flask(python)

Не могу проанализировать причину, кто останавливает сервис.

Содержимое

/etc/systemd/system/myservice.service :

[Unit]
Description=My Service
After=network-online.target
After=mysql.service
Requires=network-online.target
Requires=mysql.service

[Service]
User=root
WorkingDirectory=/home/myservice
ExecStart=/usr/bin/python3 /home/myservice/run.py
Restart=always

[Install]
WantedBy=multi-user.target

Вывод

journalctl -u myservice.service

ничего критичного не выводит, никаких критических завершений работы процесса.

Содержимое

syslog

в то время (Feb 4 06:18:19) когда сервис остановился без понятной причины: syslog @ pastebin

uname -a

Linux tasgas 5.4.0-97-generic #110-Ubuntu SMP Thu Jan 13 18:22:13 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Что инициировало останов сервиса? Как проанализировать что инициировало останов сервиса?

PS: Я не настоящий сис.админ, прошу помидорами не кидаться

Comments

[shurshur]

Для начала стоит посмотреть systemctl status myservice

[ALLIGATOR]

shurshur, смотрел, там ожидаемо "Active: inactive" в этот момент. Или там есть ещё какие-то поля которые дадут подсказку о причине останова?

[shurshur]

ALLIGATOR, если других данных нет то посмотреть насколько быстро он падает. Возможно сразу. Там virtualenv случайно не используется?

[ALLIGATOR]

shurshur, в том то и дело, что падает оно редко - за год два раза такая ситуация была. Повторить не представляю каким образом. virtualenv нету, голый питон с установленными в систему зависимостями

Я так понимаю этот останов считается штатным завершением работы, потому-что сервис не перезапускается... Restart=always

Там в syslog'е видно, что ещё и mysql почему-то тоже рестартует, но он сам потом запускается, а мой сервис так и остаётся незапущенным

[korsar182]

Используйте supervisor.

[shurshur]

ALLIGATOR, скорее всего mysql падает, а приложение не умеет корректно это обрабатывать. При этом база рестартует не моментально, а сервис достаточно быстро, и коннект к базе становится неудачным. После нескольких неудачных рестартов приложения (которое сразу же падает опять) systemd перестаёт его рестартить часто. Можно смотреть настройки по частоте и количеству перезапусков упавшего сервиса. Но я бы попробовал научить приложение переживать разрыв соединения с базой.

Я решал похожую проблему, вынес работу с базой (Oracle) в отдельный класс, который при исключениях базы переустанавливал коннект к ней и повторял запрос.

def _execute(self, query, params):
    if params:
      self.cc.execute(query, params)
    else:
      self.cc.execute(query)
    return self.cc

  def execute(self, query, params=None):
    self.connect()
    try:
      self._execute(query, params)
    except (cx_Oracle.OperationalError, cx_Oracle.DatabaseError):
      self.db = None
      self.connect()
      self._execute(query, params)
    return self.cc

[ALLIGATOR]

shurshur, Я бы согласился с такой точкой зрения, но в случае нескольких неудачных попыток рестарта - запись об этом должна логироваться в журнал. В журнале такой записи нет (см. syslog)

korsar182, как вариант наверное, но хотелось бы понять причину

[shurshur]

ALLIGATOR, я не джедай по systemd и проблемы с ним обычно решаю с помощью гугла. Подозреваю, что при слишком быстром падении сервиса он его не рестартует вообще или рестартует со слишком большим интервалом.

Гугл подсказывает параметры StartLimitIntervalSec, StartLimitBurst. Можно посмотреть какие сейчас systemd show myservice.

Вот тут есть примеры настройки: https://serverfault.com/questions/736624/systemd-s...

[AlexVWill]

может причина и непонятна, но я бы в Cron внес скрипт, который раз допустим в минуту бы проверял состояние сервиса, и при наличии inactive просто бы его перезапускал...

[ALLIGATOR]

AlexVWill, Спасибо, похоже так и сделаю
shurshur, Да, спасибо!

Вопрос не закрыт - если вдруг кто-то имеет рецепт как раскрутить эту цепочку в обратном направлении - т.е. что стало инициатором завершения сервиса systemd буду рад услышать
Может какой-то журнал аудита можно включить или трейс какой-то.... я в этом не сильно силён, может кто-то подскажет...

[Максим Гришин]

ALLIGATOR, имхо правильно вести логи самого приложения, и потом по ним смотреть, почему оно упало.

[ALLIGATOR]

Максим Гришин, По предыдущему опыту работы с этим приложением могу сказать, что если оно падает - то в журнал сервиса systemd пишется стандартный питоний стектрейс

Журнал я смотрел - там пусто

[Валентин]

AlexVWill,

может причина и непонятна, но я бы в Cron внес скрипт, который раз допустим в минуту бы проверял состояние сервиса, и при наличии inactive просто бы его перезапускал...

Зачем делать это кроном, когда systemd сам это умеет? Вот одну опцию про Restart в бнит добавили, но есть же еще и другие - таймаут, интервал, количество попыток.

Answer 1

[Vitaly Karasik]

в то время (Feb 4 06:18:19) когда сервис остановился без понятной причины:

Это сделали или пользователь или cronjob.
1) посмотрите .bash_history всех пользователей
2) посмотрите какие cron запускаются в это время (/var/spool/cron/crontabs или что-то похожее, плюс /etc/crontab , /etc/cron*)

Answer 2

[Валентин]

У вас в логе есть такие строки:

Feb  4 06:18:19 ubuntu-server systemd[1]: Reloading.
Feb  4 06:18:19 ubuntu-server systemd[1]: Stopping My Service...
Feb  4 06:18:19 ubuntu-server systemd[1]: myservice.service: Succeeded.
Feb  4 06:18:19 ubuntu-server systemd[1]: Stopped My Service.
Feb  4 06:18:19 ubuntu-server systemd[1]: Stopping MySQL Community Server...
Feb  4 06:18:20 ubuntu-server systemd[1]: mysql.service: Succeeded.
Feb  4 06:18:20 ubuntu-server systemd[1]: Stopped MySQL Community Server.
Feb 4 06:18:20 ubuntu-server systemd[1]: Reloading.

Они говорят нам о том, что кто-то вызвал systemctl daemon-reload (а эту команду вызывают, когда редактируют файлы юнитов), а потом кто-то специально запустил остановку myservice и mysql сервисов. Соответственно никакая автоматизация вам тут не поможет, смотрите, кто логинился на сервер в это время, и спрашивайте у этого человека, что он редактировал и зачем останавливал ваше приложение.

P.S. от рута запускать код на питоне, да еще и с сетью работающий, судя по зависимостям - плохая идея. Выглядит так, будто у вас нет в компании сис.админа, который бы вам настроил нормально всё.

Comments

[ALLIGATOR]

С Постскриптумом согласен, любая RCE и ты рут

А основную часть ответа надо обмозговать

(я на сервере один пользователь, сервер - VPS на DO)