Может ли systemd обнаруживать и уничтожать зависшие процессы?

Работая над решением, использующим блокировку файлов, я считаю, что мой код зашел в тупик. Я использую systemd, чтобы запустить процесс при запуске системы. Использование alarm (3) - вариант, но мне было интересно, есть ли способ для systemd обнаружить зависшие процессы и перезапустить их?

В настоящее время, чтобы обойти эту проблему, я планирую просмотреть вывод journalctl, и если он не будет изменяться в течение определенного периода времени, я убью процесс с помощью сценария оболочки.

Просто интересно, есть ли лучший способ отслеживать процессы через systemd или иным образом.

monitoring systemd

— вольнодумцем
источник

Возможно нет. Как вы говорите, если процесс завис? Что если вам действительно нужно что-то подобное for(;;) do_something();?

— mvp

Строго говоря, если ваш код зависает, вы должны отладить эту проблему. Убить его с помощью systemd (предположим, что это можно сделать, а я в это не верю) или любым другим способом - это то, что нужно делать при отладке. Но вы просто не можете оставить его свободным, чтобы зайти в тупик.

— MariusMatutiae

Да; но сначала исправьте свою глючную программу, прежде чем возиться с systemd.

MariusMatutiae совершенно правильно. У вас проблема с вашей программой. Это тупики. Возиться с systemd не ответ. В лучшем случае это отвлечение. Исправьте вашу программу, чтобы она не сломалась. Направьте свою энергию на нужную вещь.

Тем не менее, другие люди будут приходить сюда из-за названия вопроса, а не самого вопроса. Для их выгоды вот ответ на заголовок, игнорируя сам вопрос:

Да, systemd может следить за демонами и автоматически перезапускать их, если они перестают говорить. Но не просто старые демоны. Как отмечает mvp, нет никакого способа узнать, что демон завис (в этой вселенной, где проблема остановки нерешаема, по крайней мере). Ни systemd, ни какая-либо другая компьютерная программа никогда не смогут с нуля определить, что какая-то случайная программа, брошенная в них, зашла в тупик или зашла в бесконечный цикл, или что-то еще. Лучшее, что вы здесь получите, это обнаружение того, что демон не выполнил регулярную операцию «сердцебиение» в течение требуемого промежутка времени.

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

Демон, который говорит на этом протоколе, чтобы использовать возможность системного сторожа ...

… Должен проверить WATCHDOG_USECпеременную среды;
… Должен вызывать sd_notify () непрерывно и часто, в течение всего срока службы, с установленной WATCHDOG=1опцией, с интервалом около WATCHDOG_USEC/ 2 («USEC» обозначает микросекунды);
... должно быть Type=notifyустановлено в его файле модуля;
… Должен иметь NotifyAccess=main(или =all) установлен в своем файле модуля;
… Должны быть установлены WatchdogSec=секунды в файле модуля.
… Должен связаться с libsystemd-daemon.so

Если вы хотите узнать подробности кодирования этого, после прочтения руководства убедитесь, что вы идете направо в StackExchange. Это SuperUser. StackOverflow находится там .

дальнейшее чтение

Леннарт Поэттеринг. 2011-04-12. Сторожевые псы . Freedesktop.org.

— JdeBP
источник

Конечно, я должен решить проблему, мое единственное намерение состояло в том, чтобы иметь временный взлом, пока я не выясню проблему. Спасибо за подробный ответ.

— свободолюбивый