03:00. Сервер исчез, мониторинг объявил сетевую аварию. Сценарий для разбора: перед исчезновением перезапустили petter — процесс, кормящий аппаратный watchdog. Если таймер остался вооружён, а новый процесс опоздал с кормлением, плата получает reset. Ни K3s, ни WireGuard для такого отказа не нужны. Но по одному обрыву графиков отличить watchdog от питания или зависания BIOS невозможно. Начинаем с journalctl -k -b -1 | rg -i 'watchdog|sp5100|iTCO'. SP5100 обслуживает драйвер sp5100tco, Intel TCO — iTCOwdt: это разные аппаратные реализации. Для выбранного устройства: cat /sys/class/watchdog/watchdog0/{identity,state,timeout,nowayout,bootstatus}. Это состояние и параметры ядра, а не доказательство исправного reset. timeleft читаем, если драйвер его предоставляет; нулевой bootstatus не исключает watchdog-reset. Причину сверяем с журналом BMC, если он есть. Безопасность рестарта petter определяется временем до следующего успешного кормления, а не статусом active у unit. При nowayout=1 закрытие устройства не разоружает таймер; Magic Close его тоже не отменяет. Передача обслуживания должна укладываться в оставшийся бюджет с запасом на задержки запуска. Универсальное правило «закрыл fd — отсчёт остановился» здесь непригодно. Семантика описана в Watchdog API ядра. Проверка на стенде включает прекращение кормления, рестарт petter и фактический возврат узла после reset. Зависание BIOS/SMM — отдельная граница: успешный тест смерти процесса не доказывает восстановление из любого аппаратного зависания. Для него нужен проверенный независимый путь управления питанием. Kubernetes не нажмёт кнопку на мёртвой плате. Практика bare-metal: https://ftops.space/?utm*source=telegram&utm*medium=smm&utm*campaign=ftops&utm*content=watchdog-sp5100-i-tco-taymery-appar