Вариант 4: поставить стандартный демон watchdog, заставить его мониторить запущенность вашей программы.
Можно сделать через стандартную опцию pidfile в watchdog.conf например.
Да, система будет перезапущена при падении программы в таком случае.
Если вам нужно перезапускать свою программу, готовая штука из репозитория называется monit, никаких своих велосипедов не нужно писать.
Для демона watchdog можно написать test/repair скрипты которые могут переподнимать какие-то демоны при падении, но ребут на мой взгляд надежнее.
А если отслеживаемая программа самописная, с pid файлами не работает? как ее мониторить? добавлять поддержку pid запускать демоном? или может проще скрипт с pgrep-ом
man start-stop-daemon, посмотрите существующие инит-скрипты
Евгений, watchdog, который идет из стандартного репозитория debian какой-то кривой. В частности, он не умеет отслеживать пропадания сети и т.п. моменты, а также способен без видимых причин перегружать устройство. Мне помогла пересборка из исходников. Т.к. аналогичная проблема есть в raspberry, скорее всего в wheezy старая версия.
А какую вы версию собрали?
В середине января брал мастер из https://sf.net/projects/watchdog/ (git://git.code.sf.net/p/watchdog/code). Сегодня там более свежая версия, её не пробовал. Январская отлично отрабатывала перезагрузку по потери связи с роутером (ради этого и собирал). Пакет не собирал, просто подменил бинарник.
После сегодняшнего обновления watchdog он своим дефолтным конфигом вгоняет WB4 в циклический ребут.
…
Mar 13 11:19:42 wirenboard daemon.err watchdog[2504]: cannot open /var/run/mqtt-wss.pid (errno = 2 = ‘No such file or directory’)
Mar 13 11:19:42 wirenboard daemon.alert watchdog[2504]: shutting down the system because of error 2
…
Поправлял прерыванием загрузки Ctrl+Pause - i - i
watchdog не сразу убивает систему. Обычно удается зайти по ssh и остановить сервис watchdog’а
так как таки правильно настроить watchdog чтобы он перезагружал контроллер при зависании?
А чем вас не устраивает стандартный конфиг?
при стандартном конфиге контроллер исправно зависает, watchdog не отрабатывает, а должен, кстати?
добавить в конфиг пинг - не выход, может зависнуть коммутатор\маршрутизатор, поэтому вопрос - как правильно настроить watchdog чтобы он перезагружал контроллер при зависании?
А что значит зависает? Через консоль недоступен?
Просто зависает, через uart не откликается, на ping не отвечает, правила не исполняются.
Везде Евгений рекомендует правильно курить man и настроить watchdog, при этом на форуме же утверждается что базовой функциональности достаточно, чтобы контроллер перезагрузился при зависании.
Может уже есть у кого набор конкретных шагов, что надо сделать чтобы watchdog гарантированно перезагрузил контроллер когда он так непонятно зависнет?
Обратите внимание, что на WB3.5 не было отдельного аппаратного watchdog-а, только встроенный в процессор.
Он, в принципе, тоже должен справляться со своими обязанностями, но нужно проверить, что конфигурация демона watchdog правильная, а нужный девайс есть в системе в /dev/ . На WB3.5 мы это не тестировали к сожалению, срок поддержки уже вышел.
Вообще симпотомы похожи на неисправность оперативной памяти. WB3.5/WB4 этому были подвержены, плюс со временем сами чипы стареют - тоже известное больное место DDR1. Диагностируется командой memtester, лечится только перепайкой чипа памяти.