Вот моя ситуация:
У меня очень редкая проблема, когда (очень) удаленная встроенная система PC / 104, работающая под управлением Debian, кажется, теряет возможность использовать любой интерфейс связи. Я не могу добраться до него через Ethernet или последовательные порты (консоль). После выключения и включения питания системные журналы не показывают ничего неправильного. Они просто резко заканчиваются и возобновляются через несколько минут или часов, когда я выключаю питание.
Я подозреваю, что система не заблокирована, потому что у меня есть сценарий python, который пытается проверить связь с google.com, и в случае сбоя он использует контакт ввода-вывода для переключения питания беспроводного модема через реле.
Итак, у меня полностью не отвечает система и модем, который отключает и выключает питание каждые десять минут той же системой. К счастью, между перезагрузками я могу использовать модем для включения и выключения процессора. И вернуться и собрать данные.
В системе есть аппаратный сторожевой таймер, и у меня есть сторожевой таймер, установленный и работающий некоторое время. В прошлый раз, когда это произошло, я попытался добавить строку:
file=/var/log/messages
в watchdog.conf, но это не помогло. Затем я прочитал это
При использовании файлового режима сторожевой таймер будет пытаться выполнить статистику (2) данных файлов. Ошибки, возвращаемые stat, будут не вызвать перезагрузку. Для перезагрузки вызов статистики должен длиться не менее одной минуты.
Я недостаточно знаю о stat, чтобы понять, как он может реагировать на потерю возможности записи на диск, но подозреваю, что он не просто зависает.
Я также только что заметил, что у watchdogd есть опция --sync, но страницы руководства не очень подробны относительно того, что произойдет в случае сбоя синхронизации. Мой интервал составляет 2 секунды, есть ли причины не синхронизировать SSD каждые две секунды?
-Спасибо
Что вы имеете в виду, говоря «если синхронизация не удалась»? На странице руководства для sync (2) говорится о кодах возврата: «sync () всегда выполняется успешно». Таким образом, единственный способ "потерпеть неудачу" в вашем случае заключается в том, что он не возвращает управление сторожевому таймеру достаточно быстро (из-за большого количества блоков для записи, медленной записи, сломанного или поврежденного диска или файловой системы или уровня ввода-вывода ядра, ... )
И если он не вернет управление сторожевому таймеру достаточно быстро, он не сможет достаточно быстро выполнить запись в / dev / watchdog, и ваш аппаратный сторожевой таймер должен вызвать перезагрузку оборудования.
stat (2) может иметь проблемы с незаписываемым диском только в случае ошибки такого типа, чтобы предотвратить чтение (ошибка ядра, поврежденный уровень ввода-вывода). И да, он мог зависнуть, если там есть проблема. Кстати, вы должны использовать «file = / var / log / messages» в сочетании с «change =», чтобы сторожевой таймер инициировал перезагрузку, если файл менялся недостаточно часто.
Что касается сторожевого таймера, вы абсолютно уверены, что аппаратный сторожевой таймер работает? Правильно ли вы модпробировали аппаратный модуль перед запуском сторожевого таймера? Об этом говорит dmesg (8)? если вы "KILL -STOP" сторожевой таймер, машина должна перезагрузиться. Если это так, вы можете попробовать добавить опцию «nowayout» в свой аппаратный модуль, чтобы исключить возможность, например, убийства OOM сторожевого таймера и, таким образом, остановки аппаратного сторожевого таймера. Вы также можете добавить «test-binary» и «test-timeout» для запуска пользовательского сценария, который будет возвращаться, если система будет считаться работоспособной или нет (и инициировать перезагрузку, если нет).