Як діагностувати випадкові заморозки?

Здається, Ubuntu завжди застигає протягом перших ~ 15 хвилин, коли він завантажується на моїй машині. Іноді це в перші 5 хвилин, іноді це займає 30 хвилин, зрідка цього ніколи не буває ...

Я не можу це відтворити детерміновано, але все одно це трапляється досить часто, я, мабуть, просто чекаю, коли це повториться.

Як я можу діагностувати заморожування, щоб з’ясувати причину ?

Зауважте близьким виборцям:
Ні, це не дублікат цього питання. Це питання стосується діагностики , а не тимчасового одужання. Відповіді на це питання говорять мені лише про те, як вбити X-сервер, використовувати Magic Combo для скидання ядра тощо тощо, що не допомагає мені з'ясувати причину.

Деякі відомості:

1. Ubuntu 11.04: 2.6.38-15-generic # 66-Ubuntu SMP x86_64 GNU / Linux

2. Миша іноді рухається, але інтерфейс ніколи не реагує.

3. Натискання Ctrl+ Alt+, F1щоб потрапити в термінал, не працює.

4. В Alt+ SysRqкомбо зробити роботу ... і , здається, тільки те , що робота, в стороні від миші (які іноді можуть пересуватися).

5. У мене не вистачає ресурсів (багато гігабайт оперативної пам’яті та простору файлової системи є вільними)

6. Можливо, відповідне обладнання (з програми Hardware Lister):

   • Адаптер бездротової мережі AR9285 (PCI-Express)

   • GT216 [GeForce GT 330M] (я використовую драйвер Nouveau, який, здається, працює добре)

Журнали завжди повинні бути вашим першим портом дзвінка. Перевірте syslog на що-небудь незрозуміле:

less /var/log/syslog

Також перевірте журнали Xserver, якщо є якісь ознаки проблеми з графічним драйвером (хоча це звучить менш вірогідно, враховуючи ваш опис):

less /var/log/Xorg.0.log

У вашому конкретному випадку ці кроки можуть не викликати нічого цікавого. У такому випадку мені буде цікаво подивитися, що відбувається у вашій системі під час розвитку проблеми. З цією метою особисто я би встановив тимчасовий журнал topвиводу з невеликими інтервалами - скажімо, кожні 5 або 10 секунд. Це, мабуть, сподівається виявити, чи процес на час виходу з диких ресурсів на момент випуску.

Зауважте, що існують альтернативи, такі як перемикання на інший tty з Ctrl+Alt+F1.. F6(щоб повернутися до GUI, це 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клавішу, щоб дістатися до дна. Ви шукаєте процеси з незвичайно високим значенням CPU або незвично високим значенням ВДЕ.

Це може чи не допоможе, але це корисна інформація.