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