Перезагрузка при зависании оборудования

Question

ОС: Ubuntu Desktop 12.04

Как я могу убедиться, что даже если ядро имеет очень низкий уровень, серьезный сбой, система перезагрузится? Или, если это невозможно, что может быть лучше для восстановления покрытия при перезагрузке?

В любом случае можно ли использовать аппаратные таймеры или прерывания для принудительной перезагрузки?

Я бы предпочел решения, которые работают на универсальном и недорогом оборудовании.

Бонусный вопрос: Вы бы порекомендовали это как стандартное решение?

Дальнейшая иллюстрация:

Допустим, я испытываю то, что кажется очень низким уровнем замораживания. (Даже магические ключи SysRq не работают)

Я не могу ssh в машину, но кажется, что рукопожатие tcp прошло успешно. (Странно? Должен к отказу приборов, верно?)

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

Исследование:

В настоящее время я смотрю на это: http://www.cyberciti.biz/tips/reboot-linux-box-after-a-kernel-panic.html, однако я не уверен, что на самом деле я нахожусь в панике, поскольку есть нет визуальных индикаторов.

Похоже, это то, что я хочу: http://manpages.ubuntu.com/manpages/hardy/man8/watchdog.8.html Однако, похоже, он использует /dev/watchdog которого, похоже, нет в моей системе. Я что-то пропустил?

Если я буду следовать проверкам здесь: http://pic.dhe.ibm.com/infocenter/lnxinfo/v3r0m0/index.jsp?topic=%2Fliaai.crashdump%2Fliaaicrashdumpnmiwatch.htm кажется, что NMI работает в моей системе, однако система не перезагружалась при сбое. Что мне здесь не хватает?

Спасибо

Answer 1

Если ваша машина не поддерживает аппаратный контроль, есть еще несколько программных механизмов ядра, которые могут вам помочь. Прежде всего, существует программная реализация сторожевого таймера, называемая softdog , которую можно использовать с watchdog таймером как настоящий аппаратный сторожевой таймер. Вы можете проверить, поддерживает ли ваше ядро программный сторожевой таймер, проверив, загружает ли modprobe softdog модуль ядра. Это также даст вам /dev/watchdog . Если ваше ядро не поддерживает softdog вам нужно собрать собственное ядро и включить CONFIG_SOFT_WATCHDOG:

config SOFT_WATCHDOG
     tristate "Software watchdog"
     select WATCHDOG_CORE
     help
       A software monitoring watchdog. This will fail to reboot your system
       from some situations that the hardware watchdog will recover
       from. Equally it's a lot cheaper to install.

       To compile this driver as a module, choose M here: the
       module will be called softdog.

Еще одним механизмом, предоставляемым ядром, является таймер зависания, включаемый опцией CONFIG_HANGCHECK_TIMER:

config HANGCHECK_TIMER
     tristate "Hangcheck timer"
     depends on X86 || IA64 || PPC64 || S390
     help
       The hangcheck-timer module detects when the system has gone
       out to lunch past a certain margin.  It can reboot the system
       or merely print a warning.

Также (по крайней мере, на x86) есть NMI Lockup Detector в качестве третьего механизма для автоматической перезагрузки вашей системы при зависаниях:

config LOCKUP_DETECTOR
     bool "Detect Hard and Soft Lockups"
     depends on DEBUG_KERNEL && !S390
     help
       Say Y here to enable the kernel to act as a watchdog to detect
       hard and soft lockups.

       Softlockups are bugs that cause the kernel to loop in kernel
       mode for more than 20 seconds, without giving other tasks a
       chance to run.  The current stack trace is displayed upon
       detection and the system will stay locked up.

       Hardlockups are bugs that cause the CPU to loop in kernel mode
       for more than 10 seconds, without letting other interrupts have a
       chance to run.  The current stack trace is displayed upon detection
       and the system will stay locked up.

       The overhead should be minimal.  A periodic hrtimer runs to
       generate interrupts and kick the watchdog task every 4 seconds.
       An NMI is generated every 10 seconds or so to check for hardlockups.

       The frequency of hrtimer and NMI events and the soft and hard lockup
       thresholds can be controlled through the sysctl watchdog_thresh.

config HARDLOCKUP_DETECTOR
     def_bool y
     depends on LOCKUP_DETECTOR && !HAVE_NMI_WATCHDOG
     depends on PERF_EVENTS && HAVE_PERF_EVENTS_NMI

Не пугайтесь зависимости от DEBUG_KERNEL , так как она в любом случае включена в большинстве ядер распространения.

Примечание. Поскольку все это программные механизмы, нет гарантии, что они обнаружат все блокировки. Как уже упоминалось в тексте справки для SOFT_WATCHDOG , существуют ситуации, в которых все не смогут восстановиться. Но перезагрузка во многих ситуациях, по крайней мере, лучше, чем зависание во всех из них. ;)