Jak zdiagnozować przypadkowe zawieszenia?

Ubuntu zawsze zawiesza się w ciągu pierwszych ~ 15 minut od uruchomienia na moim komputerze. Czasami jest to pierwsze 5 minut, czasem 30 minut, czasem nigdy się nie zdarza ...

Nie mogę odtworzyć tego deterministycznie, ale i tak zdarza się to dość często, że prawdopodobnie po prostu czekam, aż to się powtórzy.

Jak zdiagnozować zamrożenie, aby ustalić przyczynę ?

Uwaga dla głosujących:
Nie, to nie jest duplikat tego pytania. To pytanie dotyczy diagnozy , a nie tymczasowego powrotu do zdrowia. Odpowiedzi na to pytanie mówią mi tylko, jak zabić X Server, użyć Magic Combo, aby zresetować jądro itp.… Co nie pomaga mi ustalić przyczyny.

Trochę informacji:

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

2. Mysz czasami się porusza, ale interfejs użytkownika nigdy nie reaguje.

3. Naciśnięcie Ctrl+ Alt+, F1aby dostać się do terminala, nie działa.

4. W Alt+ SysRqcombo zrobić pracę ... i wydają się być tylko rzeczy, że praca, oprócz myszy (co czasem może również poruszać).

5. Nie brakuje mi zasobów (wiele gigabajtów pamięci RAM i miejsca w systemie plików jest za darmo)

6. Prawdopodobnie odpowiedni sprzęt (z aplikacji Hardware Lister):

   • AR9285 Bezprzewodowa karta sieciowa (PCI-Express)

   • GT216 [GeForce GT 330M] (Używam sterownika Nouveau, który wydaje się działać dobrze)

Dzienniki powinny zawsze być pierwszym portem zawinięcia. Sprawdź syslog pod kątem jakichkolwiek działań niepożądanych:

less /var/log/syslog

Sprawdź także dzienniki Xserver, na wypadek, gdyby pojawiły się jakieś oznaki problemu ze sterownikiem karty graficznej (choć wydaje się to mniej prawdopodobne, biorąc pod uwagę twój opis):

less /var/log/Xorg.0.log

W twoim szczególnym przypadku kroki te mogą nie rzucić niczego interesującego. W takim przypadku chciałbym zobaczyć, co dzieje się w twoim systemie w momencie wystąpienia problemu. W tym celu osobiście ustawiałem tymczasowy dziennik topwyników w krótkich odstępach czasu - powiedzmy co 5 lub 10 sekund. Miejmy nadzieję, że powinno to ujawnić, czy w momencie wystąpienia problemu proces działa z zasobami.

Zauważ, że istnieją alternatywy, takie jak przejście na inny tty za pomocą Ctrl+Alt+F1.. F6(aby wrócić do GUI, to Ctrl+Alt+F7) i interakcyjne uruchamianie poleceń lub konfiguracja serwera SSH i zdalne logowanie. Oba mogą być niewygodne, jeśli twoja maszyna jest bardziej bezbronna lub nie odpowiada, stąd moja bardziej niezręczna sugestia, aby napisać plik dziennika (który może również napotkać ten sam problem, ale jest bardziej prawdopodobne, że odniesie sukces).

Wymagałoby to czegoś takiego:

while [ 1 -eq 1 ] ; do top -b >> ~/top.log; sleep 10; done

Spowoduje to zapisanie topdanych wyjściowych do pliku dziennika na ~ / top.log co około 10 sekund. Zauważ, że ten dziennik urósłby dość duży, gdyby to polecenie działało przez dłuższy czas, więc miej je na oku, jeśli twoja maszyna nagle zacznie się zachowywać! I po zakończeniu usuń dziennik rm ~/top.log. Zauważ też, że wykonanie powyższego polecenia jest jednorazowe; nie uruchomi się ponownie po ponownym uruchomieniu.

Aby odczytać dzienniki wygenerowane po awarii, należy użyć

less ~/top.log

i naciśnij Endklawisz, aby zejść na dół. Będziesz szukał procesów o niezwykle wysokiej% wartości procesora lub niezwykle wysokiej wartości RES.

To może, ale nie musi pomóc, ale jest to przydatne informacje.