Я использую Ubuntu 10.04 (x64) в качестве сервера web / mysql.
Сервер перестал отвечать на SSH, Ping, HTTP и т. Д., И технический специалист с физическим доступом к машине прислал мне этот снимок экрана:
http://img442.imageshack.us/img442/389/img00062201012211332.jpg
с подключенного монитора до перезагрузки (и ситуация исправлена). Я не уверен, в каком журнале хранится эта информация, так как я не могу найти текст после проверки журналов после перезагрузки.
Может ли кто-нибудь помочь мне разобраться в случившемся, чтобы убедиться, что этого больше не повторится?
Спасибо
Если у вас нет другой информации (как сказал ring0, она не будет где-то сохранена на диск), то вы больше ничего не можете сделать.
Если вы хотите действовать на опережение или это случается еще несколько раз случайным образом, вы можете попробовать LKCD для захвата дампа ядра. http://lkcd.sourceforge.net/
Я не знаю, сколько у вас оперативной памяти, но даже попытка memtest86 на пару часов может быть полезной. Очевидно, что действительно редких ошибок он не улавливает.
Я также предлагаю вам добавить kernel.panic = 5 /etc/sysctl.conf. Это приведет к автоматической перезагрузке сервера через 5 секунд, если ядро снова зависнет.
Наконец, я считаю, что у вас всегда должно быть какое-то средство защиты от света. Затем вы можете войти в систему, скопировать сообщение и самостоятельно перезапустить сервер.
Паника в ядре может быть вызвана множеством причин, обычно это либо проблема модуля (драйвер, который не подходит вашему оборудованию), либо проблема с оборудованием.
В вашем случае, если проблема не повторяется, скорее всего, она связана с оборудованием.
И это может быть память (плохую память не всегда легко определить).
Я бы загрузил сервер и выбрал во время экрана grub (сразу после загрузки) опцию "memtest86". Тест памяти необходимо проводить несколько дней подряд.
Если через 3 дня ошибки нет, память исправна. может быть хорошо.
Я видел такие сбои, когда серверы работали со слишком высокой нагрузкой / слишком большим количеством процессов в течение длительного периода времени. Чтобы в целом проверить, что происходит на вашем компьютере, я рекомендую установить на вашем сервере фреймворк мониторинга, такой как munin - это поможет в анализе, если это повторится.
Хорошо, это трассировка стека от ядра. Я не эксперт по ядру, но причина связана с прерываниями, балансировкой прерываний (прерывания) и, возможно, PIC. Однако это чаще встречается на оборудовании портативных компьютеров, чем на серверах. Неисправное решение для ноутбука - загрузка с опцией ядра noapic.
Это может показаться немного странным, но у меня были проблемы с Ubuntu x64, работающим на сервере, который был 64-битным. У меня очень часто возникали эти же ошибки и последующие проблемы с "зависанием". Он пытался удалить драйверы, добавить обратно драйверы, часами просматривал ошибки, но ничего не помогало. Я наконец решил это, установив 32-битную версию Ubuntu. Сработало, 64 бит мне не понадобилось, так что пустил. Это не лучшее решение, если вам нужна 64-разрядная версия, но это может дать вам дорогу для небольшого изучения. Возможно, найдите сервер, на котором работает Ubuntu, и посмотрите, есть ли проблемы с совместимостью. Удачи.
