Watchdog linux что это

Установка и настройка Watchdog

Сторожевой таймер (Watchdog timer) — аппаратно реализованная схема контроля над зависанием системы. Представляет собой таймер, который периодически сбрасывается контролируемой системой. Если сброса не произошло в течение некоторого интервала времени, происходит принудительная перезагрузка системы. В некоторых случаях сторожевой таймер может посылать системе сигнал на перезагрузку («мягкая» перезагрузка), в других же — перезагрузка происходит аппаратно (замыканием сигнального провода RST или подобного ему).

Установка в Linux Ubuntu/Debian:

Список некоторых файлов которые будут установлены в систему:

Возможные параметры конфига /etc/watchdog.conf:

Если пишутся логи, можно пропускать запись событий каждое указанно количество интервалов. Например если logtick = 60 и interval 10, получится 600 секунд, то есть в логируемый файл будет добавляться запись не чаще одного раза в 10 минут.

Максимально разрешенное значение загрузки системы за 1 минуту при превышении которого система перезагрузится. 0 — отключает проверку.

Максимально разрешенное значение загрузки системы за 5 минуту при превышении которого система перезагрузится. 0 — отключает проверку.

Максимально разрешенное значение загрузки системы за 15 минуту при превышении которого система перезагрузится. 0 — отключает проверку.

Установка минимального количества виртуальной памяти которое должно быть свободно. 0 — проверка отключено.

Установка максимально разрешенной температуры.

Установка имени устройства.

Установка имени устройства температуры.

Файловый режим, проверка файлов.

Интервал времени для файлового режима.

Имя pid файла. Можно добавить отслеживаемый процесс, например «pidfile = /var/run/apache2.pid». В случае невозможности запуска процесса watchdog будет постоянно перезагружать систему.

Режим пинга, для проверки сетевых соединений. Опция может быть использована более одного раза.

Установка имени сетевого интерфейса.

Выполнение пользовательского теста.

Тест может выполняться указанное количество секунд. 0 — неограничено.

Выполняется при невозможности перезагрузки системы.

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

Yes для невозможности выгрузки watchdog из оперативной памяти.

Установка приоритета для режима realtime.

Пример настройки с Intel TCO Watchog Timer.
Загрузка модуля:

В /etc/watchdog.conf должно быть раскоментировано/добавлено:

В /etc/default/watchdog указать имя модуля:

Можно добавить опцию отладки чтобы в syslog журнал писалась отладочная информация:

Мониторить в реальном времени записи syslog можно командой:

Источник

Настройка watchdog в Linux

Установка в Linux Ubuntu/Debian:

Список некоторых файлов которые будут установлены в систему:
/etc/init.d/watchdog
/etc/init.d/wd_keepalive
/etc/watchdog.conf
/etc/default/watchdog
/dev/watchdog
/usr/sbin/watchdog
/usr/sbin/wd_identify
/usr/sbin/wd_keepalive
/usr/share/doc/watchdog/
/usr/share/man/man5/watchdog.conf.5.gz
/usr/share/man/man8/watchdog.8.gz
/usr/share/man/man8/wd_identify.8.gz
/usr/share/man/man8/wd_keepalive.8.gz

logtick =
Если пишутся логи, можно пропускать запись событий каждое указанно количество интервалов. Например если logtick = 60 и interval 10, получится 600 секунд, то есть в логируемый файл будет добавляться запись не чаще одного раза в 10 минут.

max-load-1 =
Максимально разрешенное значение загрузки системы за 1 минуту при превышении которого система перезагрузится. 0 — отключает проверку.

max-load-5 =
Максимально разрешенное значение загрузки системы за 5 минуту при превышении которого система перезагрузится. 0 — отключает проверку.

max-load-15 =
Максимально разрешенное значение загрузки системы за 15 минуту при превышении которого система перезагрузится. 0 — отключает проверку.

min-memory =
Установка минимального количества виртуальной памяти которое должно быть свободно. 0 — проверка отключено.

max-temperature =
Установка максимально разрешенной температуры.

watchdog-device =
Установка имени устройства.

temperature-device =
Установка имени устройства температуры.

file =
Файловый режим, проверка файлов.

change =
Интервал времени для файлового режима.

Имя pid файла. Можно добавить отслеживаемый процесс, например «pidfile = /var/run/apache2.pid». В случае невозможности запуска процесса watchdog будет постоянно перезагружать систему.

ping =
Режим пинга, для проверки сетевых соединений. Опция может быть использована более одного раза.

interface =
Установка имени сетевого интерфейса.

test-binary =
Выполнение пользовательского теста.

test-timeout =
Тест может выполняться указанное количество секунд. 0 — неограничено.

repair-binary =
Выполняется при невозможности перезагрузки системы.

admin =
Адрес email для уведомлений, можно оставить значение пустым для отключения.

realtime =
Yes для невозможности выгрузки watchdog из оперативной памяти.

priority =
Установка приоритета для режима realtime.

Пример настройки с Intel TCO Watchog Timer.
Загрузка модуля:

В /etc/watchdog.conf должно быть раскоментировано/добавлено:

В /etc/default/watchdog указать имя модуля:

Можно добавить опцию отладки чтобы в syslog журнал писалась отладочная информация:

Мониторить в реальном времени записи syslog можно командой:

Источник

Аппаратный «watchdog» или незаменимый помощник в борьбе с зависанием

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

В итоге мы получили устройство, которое подключается к расширительному спаренному USB-разъему на материнской плате.

Данное устройство имеет следующие возможности:

Алгоритм работы прост: внутри находятся два настраиваемых таймера, которые постоянно отсчитывают заданное время, по истечению которого имитируется нажатие соответствующих кнопок (POWER и RESET). Чтобы предотвратить случайную перезагрузку, необходимо периодически послать команду сброса таймера.

Лучше, чтобы за процедуру сброса таймеров отвечало целевое приложение, а не стороннее или системное (Cron, служба расписаний) по причине того, что вероятность сбоя в системе меньше, чем в приложении (хотя, у кого как).
Обмен информацией аналогичен консольному.

В случае удачного выполнения команды возвращает «OK».
В случае некорректных данных возвращает «ERROR».
Признаком конца строки служит символ возврата каретки «\r». Также поддерживается режим «\r\n».

Устройство выполнено на базе контроллера STM32F103CA с аппаратной поддержкой USB. Библиотека работы с USB версии V4.0.0. Напряжение работы 3.3В получаем с помощью линейного стабилизатора из 5В на USB. Во всех управляющих цепях используются транзисторы в ключевом режиме. Также не забываем про защитный диод от токов самоиндукции в катушки реле (в моем случае он оказался встроенным).

Источник

Развёртывание и настройка oVirt 4.0. Часть 5. Watchdog как средство повышения доступности гостевых систем виртуальных машин

Продолжая тему возможностей обеспечения высокой доступности (High Availability) в oVirt 4.0 нельзя упустить из виду такой функционал, как поддержка виртуальных устройств Watchdog. В этой заметке мы рассмотрим практический пример настройки Watchdog-устройства в виртуальной машине с гостевой ОС Ubuntu Linux 16.04 LTS.

Итак, рассмотрим пример настройки Watchdog для ВМ с гостевой ОС Ubuntu Linux 16.04.1 LTS.

После загрузки нашей виртуальной машины с гостевой ОС Ubuntu Linux убедимся в том, что в системе появилось новое Watchdog-устройство:

Установим соответствующую службу из пакета watchdog

Для проверки подгружаем модуль ядра с драйвером для поддержки нашей модели Watchdog-устройства:

После этого попробуем включить и запустить службу watchdog:

Служба, как минимум, должна запуститься без ошибок:

В файле блэк-листа /etc/modprobe.d/blacklist-watchdog.conf среди множества строк находим и комментируем строку с названием нужного нам модуля ядра, чтобы разрешить его загрузку:

В целом проделанных действий должно быть достаточно, однако, как показывает практика, в некоторых случаях при загрузке системы служба watchdog не стартует, поэтому в конец файла /etc/rc.local можно добавить излюбленный «костыль», который после запуска системы будет выполнять сначала проверку наличия в системе watchdog-устройства, а затем, если это устройство есть, будет выполнять проверку состояния службы watchdog, и если необходимо инициировать запуск этой службы.

В конце проделанной настройки перезагружаем наш виртуальный сервер c Ubuntu (можно для проверки несколько раз) и убеждаемся в том, что после каждого запуска системы служба watchdog успешно стартует. Если с авто-запуском службы проблем нет, можем переходить к проверке совместной работы виртуального watchdog-устройства и watchdog-службы.

Для проверки из под root выполним команду, которая вызовет «краш» нашей гостевой Linux-системы:

После перезагрузки наша гостевая ОС снова в работе, а пара watchdog-устройство/watchdog-служба снова будет нести для нас свою «нелёгкую вахту».

В связи с тем, что не так давно появилась новая версия oVirt 4.0.3, в следующей части серии заметок посвящённых oVirt, мы рассмотрим процедуру обновления oVirt Hosted Engine до актуальной новой версии внутри 4 ветки.

Дополнительные источники информации:

Источник

Мониторинг за изменениями файловой системы

Установка

Можно взять готовую версию из PIP:
$ pip install watchdog
Сам PIP ставится как пакет python-pip, порт devel/py-pip, etc.
Либо собрать из исходников через setup.py.

Достаточно подробно все расписано в оригинальном руководстве. Правда там описание версии 0.5.4, а сейчас актуальна 0.6.0. Однако, вся разница в правке копирайтов и замене отступа в 4 пробела на отступ в 2. «Google code style» 🙂

Вообще, там довольно много особенностей сборки по версиям самого python так и по целевой платформе. Они все описаны по ссылке выше, но если будет нужно, допишу в статью вкратце на русском.

Кроме того, собрать модуль можно на несовместимой ОС, но тогда в дело вступится fallback-реализация, делающая «слепки» структуры ФС с последующими сравнениями. Возможно, так кто-то и делал у себя при решении подобной задачи 🙂

Сам же я пробовал собрать под ubuntu 11.4 и freebsd-8.2 RELEASE, каких-либо проблем при сборке и работе не возникло.

Базовый пример

Предположим, что нас интересуют изменения по некоему пути /path/to/smth, связанные с созданием, удалением и переименованием файлов и директорий.

Класс Observer выбирается в /observers/__init__.py исходя из возможностей вашей ОС, так что нет необходимости самостоятельно решать, что же выбрать.
Класс FileSystemEventHandler является базовым классом обработчика событий изменения. Он мало что умеет, но мы научим его потомка:

Полный список методов можно увидеть в самом FileSystemEventHandler.dispatch: on_modified, on_moved, on_created, on_deleted.

Observer является относительно далеким потомком threading.Thread, соотвественно после вызова start() мы получаем фоновый поток, следящий за изменениями. Так что если скрипт сразу завершится, то ничего толкового мы не получим. Реалиация ожидания зависит в первую очередь от применения модуля в реальном проекте, сейчас же можно просто сделать костыль:

Ждем событий изменений ФС до прихода Ctrl+C (SIGINT), после чего говорим нашему потоку завершиться и ждем, пока он это выполнит.

Запускаем скрипт, идем по нашему пути и:

На выходе скрипта имеем:

В методы нашего класса Handler в поле event приходят потомки FileSystemEvent, перечисленные в watchdog/events.py.
У всех есть свойства src_path, is_directory, event_type («created», «deleted», и т.п.). Для события moved добавляется свойство dest_path.

Ну если вы больше ничего не хотите… А разве ещё что-нибудь есть?

RegexMatchingEventHandler делает тоже самое, но с явным указанием regexp-выражений в конструкторе:

PatternMatchingEventHandler внутри себя в итоге транслирует шаблоны в регулярки, так что должен работать медленнее из-за наличия такого оверхеда.

Наконец, LoggingEventHandler выводит все в лог через logging.info().

— Вот и все. Может кому пригодится.

P.S.
При слежении за директорией, в которой (и в ее дочерних) содержатся папки/файлы не с ascii именованием, возникнет исключение exceptions.UnicodeEncodeError в глубинах watchdog’а. В Linux (inotify) он возникает в watchdog.observers.inotify.Inotify._add_watch.
Причина — чтение содержимого в ascii кодировке.
Для исправления ситуации можно пропатчить метод:

Вот пример исходной строки, и ее repr() до и после обработки encode():

Источник