Как диагностировать случайные замораживания?
Ubuntu всегда, кажется, замораживается за первые ~15 минут того, когда она загружается на моей машине. Иногда это находится за первые 5 минут, иногда требуется 30 минут, иногда этого никогда не происходит...
Я не могу воспроизвести его детерминировано, но это происходит достаточно часто так или иначе, что я, вероятно, просто ожидаю его для случая снова.
Как я могу диагностировать замораживание для выяснения причины?
Примечание избирателям завершения:
Нет, это не дубликат этого вопроса. Этот вопрос о диагнозе, не временном восстановлении. Ответы по тому вопросу только говорят мне, как уничтожить X-сервер, используйте Волшебную Комбинацию для сброса ядра, и т.д....., который не помогает мне выяснить причину.
Некоторая информация:
Ubuntu 11.04: 2.6.38-15-универсальный # GNU/Linux SMP x86_64 с 66 Ubuntu
Мышь иногда перемещается, но UI никогда не отвечает.
Нажатие Ctrl+Alt+F1 для вхождения в терминал не работает.
Комбинации Alt+SysRq действительно работают... и, кажется, единственные вещи, которые работают кроме мыши (который иногда также может переместиться).
У меня не заканчиваются ресурсы (много гигабайтов RAM, и пространство файловой системы свободны),
Возможно соответствующая аппаратная (из приложения Hardware Lister):
Адаптер беспроводной сети AR9285 (PCI Express)
GT216 [GeForce GT 330M] (я использую драйвер Nouveau, который, кажется, работает хорошо),
1 ответ
Журналы всегда должны быть вашим первым портом захода. Проверьте системный журнал на предмет каких-либо неприятных событий:
less /var/log/syslog
Также проверьте журналы Xserver в случае, если есть какие-либо признаки проблемы с графическим драйвером (хотя это звучит менее вероятно, учитывая ваше описание):
less /var/log/Xorg.0.log
В вашем конкретном случае эти шаги могут не вызвать ничего интересного. В этом случае мне было бы интересно посмотреть, что происходит в вашей системе во время разработки проблемы. Для этого лично я бы настроил временный журнал вывода top через короткие интервалы - скажем, каждые 5 или 10 секунд. Мы надеемся, что это покажет, насколько процесс запущен с ресурсами во время проблемы.
Обратите внимание, что существуют альтернативы, такие как переключение на другой tty с помощью Ctrl + Alt + F1 .. F6 (чтобы вернуться в графический интерфейс, это < kbd> Ctrl + Alt + F7 ) и выполнение команд в интерактивном режиме или настройка SSH-сервера и удаленный вход в систему. И то и другое может быть неловко, если ваша машина более или менее не отвечает, поэтому мое более неловкое предложение написать файл журнала (который мог бы также столкнуться с той же проблемой, но с большей вероятностью преуспел).
Это может включать в себя что-то вроде этого:
while [ 1 -eq 1 ] ; do top -b >> ~/top.log; sleep 10; done
Это будет записывать вывод top в файл журнала в ~ / top.log каждые 10 секунд или около того. Обратите внимание, что этот журнал может вырасти довольно большим, если эта команда будет выполняться в течение длительного периода, поэтому следите за ним, если ваша машина неожиданно начнет работать сама! И удалите журнал с rm ~/top.log, когда вы закончите с ним. Также обратите внимание, что выполнение вышеупомянутой команды является одноразовым; он не перезапустится после перезагрузки.
Чтобы прочитать журналы, сгенерированные после сбоя, вы должны использовать
less ~/top.log
и нажать клавишу End , чтобы добраться до конца. Вы бы искали процессы с необычно высоким значением% процессора или необычно высоким значением RES.
Это может помочь, а может и не помочь, но это полезная информация.