SystemD перезапустить задания при условии

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

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

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

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

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

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

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

Каково было бы лучшее решение для решения этой проблемы?

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

Источник

2 ответа

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

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

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

Источник

Я думаю, что ваша проблема в том, что ваша программа может аварийно завершить работу, но вина нет, поэтому 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 минут (или что-то еще, что имеет смысл для ваших нужд)
  • если файлы сбоев отсутствуют, модуль таймера не запускается, и основная служба Uploader продолжает работать
  • если есть файлы сбоев, запустите некоторый пользовательский скрипт, чтобы сделать с ними правильные действия, и перезапустите наш модуль таймера (который, из-за PartOf, должен также перезапустить основной сервис Uploader)

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

Источник
Другие вопросы по тегам