Назад | Перейти на главную страницу

linux зависает - как узнать, причина в аппаратном или программном обеспечении?

Пару недель назад мой Linux-сервер (kubuntu 10.04) начал вызывать у меня проблемы.

он зависает после определенного времени безотказной работы, по-видимому, от пары минут до нескольких часов - графический интерфейс не отвечает, нет реакции на мышь или клавиатуру (даже REISUB), top в ssh сеанс перестает обновляться, и сам сеанс прерывается по истечении тайм-аута:

Read from remote host 10.1.1.9: Operation timed out
Connection to 10.1.1.9 closed.

Тогда я предполагал, что проблема в оборудовании, поэтому я начал заменять все больше и больше оборудования - видеокарты, материнская плата, процессор, оперативная память, жесткие диски, блок питания. теперь я заменил всю машину, но она все еще зависает.

я проверил /var/log/messages и некоторые другие логи - в них вообще нет ни малейшего понятия. проблема с оборудованием кажется маловероятной, учитывая, что все было заменено, но все же возможно.

Я урезал машину до минимума. Я загружаю живую систему kubuntu с USB-накопителя, монтирую пару жестких дисков только для чтения и начинаю на них различать папки. это, кажется, обеспечивает надежное замораживание. до сих пор я не работал дольше нескольких часов.

мой сервер не работает, это продолжается уже несколько недель. Моя мудрость подошла к концу, и я хватаюсь за соломинку.

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

Вам нужно получить аварийный дамп и просмотреть его. Просмотр журналов не поможет, так как в них ничего не будет записано в случае паники / упс ядра. Если у вас есть доступ к консоли, вы можете увидеть, есть ли сообщение о панике. Аварийный дамп будет содержать содержимое кольцевого буфера ядра (то, что вы увидите в dmesg, если он будет записан на диск). Если это не помогает, нужно начинать полный анализ дампа.

https://wiki.ubuntu.com/Kernel/CrashdumpRecipe?action=show&redirect=KernelTeam%2FCrashdumpRecipe

похоже, это начало для Ubuntu. Погуглите "технический документ о сбоях Redhat", который также даст вам несколько советов.

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

Что, если вместо Kubuntu 10.04 вы попробуете какой-нибудь совершенно другой дистрибутив? Загрузите какой-нибудь другой живой дистрибутив, например openSUSE или даже какой-нибудь вариант BSD, и посмотрите, воспроизводят ли они также замораживание. Таким образом, вы можете быть уверены, что это не какая-то ошибка в Kubuntu 10.04.

Сколько данных у вас есть в деревьях каталогов, которые вы сравниваете? И что еще более важно, есть только пара больших файлов или огромное количество маленьких файлов?

Когда вы заменили жесткие диски, как вы скопировали данные со старого диска на другой? dd_rescue или какая-нибудь программа для обработки изображений? Просто старый cp? Если вы использовали какую-то программу создания образов или dd_rescue, а исходная файловая система каким-то образом содержала какие-то странные повреждения, возможно, diffing попадает в поврежденную область и вызывает сбой? Редко и маловероятно, но, безусловно, возможно. Точно так же возможно, что вас там ударит молния.

Что касается температуры, попробуйте запустить какое-нибудь программное обеспечение для мониторинга датчиков и посмотрите, что он показывает в момент замерзания.

Для KDE (если вы используете Kubuntu: http://kde-look.org/content/show.php/Sensors-Monitor