Сервер разработки, за который я отвечаю (ext3 в raid 5 с Debian Squeeze), завис на выходных, и я был вынужден сбросить его, так как не отвечал при доступе к KVM / физической клавиатуре, не отвечали устройства eth и т. Д. процесс резервного копирования запущен (цифры, один раз я не проверял на подтверждение)
Итак, после сброса оказывается, что каждый след диск IO активность, которая должна была произойти в течение ~ 24 часов, полностью исчезла. В файлах журнала есть большие пробелы в дате и времени. Как будто записи никогда не фиксировались на диск, казалось, что никакие процессы не выполняются.
К счастью, это были выходные, и ничего ценного не было потеряно, и я не подозреваю о взломе.
Что я могу сделать после вскрытия этого события, чтобы оно никогда не повторилось? Я видел, как это происходило раньше на совершенно другой машине под управлением FreeBSD.
Я сейчас собираюсь рассказать об инструментах проверки диска - но должно быть что-то еще!
/dev/sda1 on / type ext3 (rw,errors=remount-ro)Linux dev 2.6.32-5-686-bigmem13%/3%Если у вас нет сообщения OOPS от ядра о том, почему оно заблокировано, вы не сможете больше устранять неполадки. Возможно, вы сможете настроить kdump для сохранения некоторых результатов отладки, если это произойдет снова, и вы можете запустить memtest86 или другую диагностику оборудования, но без дополнительной информации вы не сможете двигаться дальше.
Звучит знакомо. У вас есть Intel-CPU? Если да, то какие у вас настройки зеленого режима в BIOS? У вас установлена последняя версия BIOS?
Какой патч Intel-Microcode-patch ваш Debian применяет во время загрузки?
У меня были похожие ситуации, когда R310 завис (по выходным, когда ничего не происходило). Это было исправлено обновлением микрокода Intel (в моем случае CentOS 5).
Dell порекомендовала обновление BIOS, которое, в свою очередь, применило то же обновление микрокода.
В других случаях я видел, что за это отвечает Intel-C-sleep-states.