Аппаратный watchdog — не справка о бессмертии сервера. Разберём сценарий отказа: мониторинг показывает K3s NotReady, SSH молчит, оператор обвиняет сеть. Но petter — процесс, посылающий keepalive, — продолжает работать, пока полезная работа узла стоит. Счётчик перезапускается каждым кормлением. Таймер исправен; ошибочен критерий, по которому ему продлевают жизнь. Сначала устанавливаем, что действительно вооружено: journalctl -k -b | grep -Ei 'watchdog|sp5100|iTCO|NO_REBOOT'; затем grep . /sys/class/watchdog/watchdog0/{identity,state,timeout,timeleft,nowayout,bootstatus}. Набор доступных атрибутов зависит от драйвера: timeleft может отсутствовать, bootstatus не обязан достоверно объяснять прошлый reset. sp5100_tco относится к поддерживаемым AMD-чипсетам, iTCO_wdt — к Intel TCO. Регистрация устройства ещё не доказывает, что прошивка разрешила аппаратный сброс. Безопасный restart petter начинается с выяснения владельца /dev/watchdog0 и поведения close. Magic Close, nowayout и обслуживание таймера ядром меняют результат: закрытие дескриптора нельзя считать ни гарантированным отключением, ни гарантированным будущим reset. Если таймер остаётся вооружён, пауза до нового keepalive должна укладываться в оставшийся срок с запасом. Проверять это впервые на узле с рабочими данными — дорогой способ читать документацию. Приёмка проводится на выведенном из нагрузки узле с доступом к BMC: проверяем прекращение кормления и фактический аппаратный reset. Такой тест проверяет этот сценарий, но не доказывает спасение при любом зависании BIOS/SMI: таймер и тракт сброса должны оставаться работоспособными. Kubernetes не починит прошивку декларацией желаемого состояния. Разбор эксплуатации bare metal: https://ftops.space/?utm_source=telegram&utm_medium=smm&utm_campaign=ftops&utm_content=watchdog-sp5100-i-tco-taymery-appar
