"Можжевельники, watchdog-и и кирпичи"
Добрый день, коллеги.
Мы продолжаем наш увлекательный цикл радиопердач по изучению продуктов жизнедеятельности индусов.
Сегодня в студии у нас Juniper SRX300.
У него, как и многих подобных устройств, есть встроенный watchdog на случай, если операционная система зависнет.
А давайте этот самый watchdog - включим?
Вводим команду:
set watchdog enable timeout 600
commit
Совершенно внезапно - получаем в итоге КИРПИЧ.
Суть кирпича - цикличный reboot.
По неизвестной причине, watchdog "стреляет" сразу, вне зависимости от указанного значения timeout.
Система перезагружается.
И через секунду после готовности, опять же, "стреляет" watchdog.
Окей, мы умные и опытные.
Вводим команду:
set watchdog enable timeout 600
commit confirmed
Система, соответственно, ПО ИДЕЕ выполнит rollback, если что-то пойдет не так.
Увы, уже не так внезапно, но все равно неожиданно - получаем в итоге КИРПИЧ.
Когда мы делаем commit confirmed, то на конфиг штатно применяется и ставится что-то типа задания at на rollback.
Но таймер этот живёт исключительно ДО перезагрузки.
А в нашем случае watchdog - неисправный. Он отправляет железку в циклический ребут.
Поэтому, даже если мы в первый же цикл в бутлодере отключим watchdog , то у нас всё равно конфиг не откатится.
А так, оно даже если бы работало, то watchdog его в ребут отсылает ОЧЕНЬ быстро.
Аналогично, я попробовал поиграть в "быстрого Гонсалеза" и попробовать удалить statement из конфига.
Не получается - watchdog перезагружает "коробку" почти мгновенно.
Не всегда успеваешь даже залогиниться.
Баг достоверно репродьюсится в Juniper SRX300 и Juniper SRX345, причем конфигурация не имеет значения - как в кластере, так и в stand-alone.
Версии Junos: 15 и 20. Уверен, что не ошибусь, если интерполирую и до Junos всех промежуточных версий а также до "коробки" SRX340.
Мне вот интересно, сколько лет еще пройдет, пока "эффективные говноменеджеры" поймут, что не стоит нанимать кумаров за тарелку риса?
Лечение после экспериментов или инцидента:
1) Перезагружаем "коробку".
2) Во время загрузки ловим момент и нажимаем "пробел"
3) В меню loader вводим две команды:
watchdog disable
boot
4) Ждём, пока система штатно загрузится.
5) Редактируем конфиг. Удаляем(!!!). Да-да, именно УДАЛЯЕМ полностью statement "watchog" из
system processes
Еще раз подчеркну: дать команду:
set system processes watchdog disable
НЕ поможет. Только удалить statement.
6) Вводим
commit
7) (Опционально) перезагружаем "коробку".
__
Мы продолжаем наш увлекательный цикл радиопердач по изучению продуктов жизнедеятельности индусов.
Сегодня в студии у нас Juniper SRX300.
У него, как и многих подобных устройств, есть встроенный watchdog на случай, если операционная система зависнет.
А давайте этот самый watchdog - включим?
Вводим команду:
set watchdog enable timeout 600
commit
Совершенно внезапно - получаем в итоге КИРПИЧ.
Суть кирпича - цикличный reboot.
По неизвестной причине, watchdog "стреляет" сразу, вне зависимости от указанного значения timeout.
Система перезагружается.
И через секунду после готовности, опять же, "стреляет" watchdog.
Окей, мы умные и опытные.
Вводим команду:
set watchdog enable timeout 600
commit confirmed
Система, соответственно, ПО ИДЕЕ выполнит rollback, если что-то пойдет не так.
Увы, уже не так внезапно, но все равно неожиданно - получаем в итоге КИРПИЧ.
Когда мы делаем commit confirmed, то на конфиг штатно применяется и ставится что-то типа задания at на rollback.
Но таймер этот живёт исключительно ДО перезагрузки.
А в нашем случае watchdog - неисправный. Он отправляет железку в циклический ребут.
Поэтому, даже если мы в первый же цикл в бутлодере отключим watchdog , то у нас всё равно конфиг не откатится.
А так, оно даже если бы работало, то watchdog его в ребут отсылает ОЧЕНЬ быстро.
Аналогично, я попробовал поиграть в "быстрого Гонсалеза" и попробовать удалить statement из конфига.
Не получается - watchdog перезагружает "коробку" почти мгновенно.
Не всегда успеваешь даже залогиниться.
Баг достоверно репродьюсится в Juniper SRX300 и Juniper SRX345, причем конфигурация не имеет значения - как в кластере, так и в stand-alone.
Версии Junos: 15 и 20. Уверен, что не ошибусь, если интерполирую и до Junos всех промежуточных версий а также до "коробки" SRX340.
Мне вот интересно, сколько лет еще пройдет, пока "эффективные говноменеджеры" поймут, что не стоит нанимать кумаров за тарелку риса?
Лечение после экспериментов или инцидента:
1) Перезагружаем "коробку".
2) Во время загрузки ловим момент и нажимаем "пробел"
3) В меню loader вводим две команды:
watchdog disable
boot
4) Ждём, пока система штатно загрузится.
5) Редактируем конфиг. Удаляем(!!!). Да-да, именно УДАЛЯЕМ полностью statement "watchog" из
system processes
Еще раз подчеркну: дать команду:
set system processes watchdog disable
НЕ поможет. Только удалить statement.
6) Вводим
commit
7) (Опционально) перезагружаем "коробку".
__