Назад | Перейти на главную страницу

systemd перезапускает задания при условии

У меня есть демон только для Windows, работающий на Linux с вином и Xvfb. Из-за этой довольно экспериментальной установки демон периодически дает сбой, и я хотел бы реализовать какой-то механизм для автоматического перезапуска демона. В настоящее время у меня есть определение модуля systemd с Restart=always настройка.

Однако я заметил, что иногда демон дает сбой, но не выходит из процесса. Это эквивалент отображения диалогового окна с вопросом «Демон разбился, хотите отправить отчет об ошибке?». Итак, процесс все еще выполняется, но демон перестал работать.

Единственное внешнее поведение этого явления, которое я могу изучить в своем Linux-окне, - это два новых файла, которые появляются в определенном месте, но с переменными именами файлов (они зависят от времени и имеют метку времени в своем имени). Я думаю, что это какой-то дамп памяти или трассировки стека, которые изначально следует использовать для отправки отчета об ошибке.

Итак, теперь я ищу решение для systemd, чтобы захватить это решение, например

  1. При запуске модуля посмотрите на целевой каталог аварийного дампа и сделайте снимок содержимого каталога.
  2. Запустить демон
  3. Периодически просматривайте каталог и, если есть новые файлы, которых нет в моментальном снимке, на основе какого-либо регулярного выражения, перезапустите демон и обновите моментальный снимок.

Я думал об оболочке, написанной на bash или чем-то подобном, но есть две проблемы: во-первых, я бы не знал, как реализовать это поведение, а во-вторых, это сделало бы использование systemd полностью устаревшим, поскольку сценарий обрабатывает всю обработку сбоев. , а systemd будет выполнять только сценарий.

Я также подумал о том, чтобы просто периодически перезапускать демон с заданными функциями systemd, но это было бы довольно неэффективно (учитывая тот факт, что демон Windows в винной оболочке не является неэффективным в первую очередь), поскольку он иногда перезапускал бы демон когда в этом нет необходимости, или может пройти некоторое время после сбоя демона, пока не сработает периодический перезапуск.

Как лучше всего решить эту проблему?

И только для записи: демон, о котором я говорю, - это программа загрузки для Google Фото. Google по каким-то причинам не выпускает его для Linux.

Хорошо, я обнаружил мощь systemd.path.

Я создал второй сервисный блок с ExecStart=systemctl restart daemon.unit и Type=oneshot. После этого я создал третий блок, блок пути с PathModified=<crashdump output directory> и Unit=daemon-restart.unit.

Теперь это работает. Мне нужно только убедиться, что никакой другой процесс не записывает в выходной каталог, но это можно решить с помощью нескольких разных винных префиксов.

Я думаю, ваша проблема в том, что ваша программа может давать сбой, а вино - нет, поэтому systemd не видит ничего плохого (PID все еще существует).

Во-первых, вы можете найти некоторую помощь в ответах на этот вопрос: Условно запустить службу SystemD?

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

В принципе, я думаю, что решение будет сводиться к умному использованию ConditionPathExistsGlob =, возможно, во вспомогательном модуле.

Хакерское решение может включать в себя таймер с таким условием PathExistsGlob, который может перезапускать вашу основную службу. Я бы предпочел, чтобы этот модуль таймера также занимался очисткой файлов / дампов, а не заставлял основной модуль делать это, но это почти наверняка вопрос вкуса.

Итак, я бы не стал трогать то, что у вас есть, а вместо этого добавил бы что-то вроде (NB: это предположение и не проверено):

[Unit]
Description=Detect and recover issues with Uploader
After=uploader.service
Requires=uploader.service
PartOf=uploader.service
AssertPathExistsGlob=/srv/uploader/crash*.dump

[Service]
Type=oneshot
ExecStart=cleanup_script
Restart=on-success

Основная логика:

  • вы запускаете это по таймеру, скажем, каждые 5 минут (или что-то еще, что имеет смысл для ваших нужд)
  • если файлов сбоя нет, таймер не запускается, и основная служба загрузчика продолжает работать
  • если файлы сбоя присутствуют, запустите какой-нибудь собственный сценарий, чтобы сделать с ними правильные действия, и перезапустите наш модуль таймера (который из-за PartOf, должен также перезапустите основную службу Uploader)

Я не говорю, что это отличное решение, но это может быть решение