Gdzie są dzienniki paniki jądra?

Mam problem z Handbrake / ffmpeg. Po około 5 minutach transkodowania komputer się blokuje. Jestem całkiem pewien, że to panika jądra, ponieważ Caps-Lock zaczyna migać.

Jest kilka logicznych pytań na temat tego, co robić, a niektóre na temat konkretnych błędów, ale naprawdę mam jedno: co się stało, zanim wszystko umarło ?!

Sprawdziłem /var/log/kern.logi wszystko, co widzę w tym czasie, to to, że wkładam DVD, a kilka minut później system się uruchamia. Bez błędów, bez paniki.

Czy jest jakiś sposób na wymuszenie rejestrowania paniki? Jestem całkiem pewien, że mogę to odtworzyć (zdarzyło się to w 100% razy, kiedy ostatnio próbowałem), więc chociaż wolę to „po prostu zadziałało”, cieszę się, że mogę uruchomić się ponownie kilka razy, jeśli oznacza to, że mogę znaleźć przyczynę paniki.

Obsługiwane są wszystkie dzienniki systemowe w systemie Ubuntu, dzięki rsyslogktórym zachowuje on swoją konfigurację w /etc/rsyslog.confi /etc/rsyslog.d/.

Aby uzyskać więcej informacji na temat konfiguracji rsyslogi możliwych opcji, odwiedź stronę rsyslog.conf man page.

Po otwarciu /etc/rsyslog.d/50-default.confwidać, że jedna z linii zawiera

*.*;auth,authpriv.none -/var/log/syslog*

Oznacza to, że plik, którego szukasz w tym przypadku, jest jednym z ogromnych /var/log/syslogdzienników, które prawdopodobnie będziesz mieć.

Możesz zobaczyć, że nazwa pliku zaczyna się również od -, co oznacza, że ​​plik jest buforowany przed zapisaniem, jest świetny, ale może pozostawić zły dziennik, a chcesz, aby dziennik został zapisany, gdy tylko wystąpi problem. Usuń kreskę i uruchom ponownie lub ponownie załaduj, rsysloga następnie ponownie spowoduj awarię komputera, sprawdź /var/log/syslog.

Jeśli naprawdę jest to panika jądra, to nie zostanie zapisana w dzienniku za pomocą normalnych metod. Ponieważ jądro uległo awarii w tym momencie, zapisywanie w systemie plików jest ryzykowną operacją - nie można już ufać zbyt dużej części jądra, więc zapisy w logach mogą powodować wyrzucanie losowych bzdur na twój bootloader!

Zamiast tego możesz zrzucić zawartość pamięci do swojej wymiany, a następnie debugować ją później. Jest to znane jako awaria jądra / zrzut rdzenia.

Ubuntu Wiki ma CrashdumpRecipe, który może być przydatny - choć wygląda na nieco nieaktualny, nie sądzę, że zbyt wiele powinno się zmienić.

Port szeregowy

Port szeregowy to prosty mechanizm komunikacji niskiego poziomu między komputerami.

Zalety:

• prosta konfiguracja raz (jeśli masz sprzęt)
• niezawodne, ponieważ transmisja danych zależy tylko od prostych interfejsów API i jądra, na które panika ma mniejszy wpływ niż na podsystem TCP / IP.

Wady:

• większość współczesnych laptopów nie ma już portu szeregowego (narażonego?), aby zaoszczędzić miejsce. Ale komputery stacjonarne i maszyny wirtualne nadal działają.
• potrzebujesz także drugiego komputera z portem szeregowym, aby odbierać dane, ale dotyczy to w zasadzie wszystkich wbudowanych płyt programistycznych, takich jak Raspberry Pi.
• ograniczona przez długość kabla szeregowego warstwy fizycznej, w przeciwieństwie do sieci TCP / IP, które są nieograniczone. Można to jednak obejść za pomocą urządzenia, które łączy interfejs szeregowy z TCP / IP. Ale są urządzenia, które konwertują między nimi.

Port szeregowy wygląda następująco:

a na RPI jest dostępny przez GPIO.

Następnie, jeśli masz wymagany sprzęt, połącz z drugiego komputera z komputerem głównym za pomocą:

screen /dev/ttyS0 115200

To faktycznie daje ci powłokę.

Następnie na głównym komputerze rozpocznij operację paniki.

Kiedy dochodzi do paniki, zrzut paniki jest przesyłany strumieniowo do drugiej maszyny i można to wszystko zobaczyć, przewijając w górę terminal.

Inne metody

Istnieją również inne metody, które pokonują wspomniane wyżej ograniczenia sprzętowe, kosztem większej złożoności i mniejszej niezawodności. Godne uwagi metody:

• netdump: przesyła transmisję paniki przez TCP / IP. Polega na tym, że podsystem TCP / IP nie jest uszkodzony.
• kdump: wydaje się być podstawowym mechanizmem linux-crashdump wspomnianym na stronie : https://askubuntu.com/a/104793/52975 Uruchamia drugie jądro Linuksa w celu zbadania uszkodzonego jądra. Co może pójść nie tak?! :-)

Zobacz także tę świetną odpowiedź: https://unix.stackexchange.com/questions/60574/determining-cause-of-linux-kernel-panic

Krok debugowania

Ostatecznie uzyskanie danych wyjściowych z paniki wymaga działania niektórych funkcji jądra, a każda funkcja jądra może zostać uszkodzona przez panikę.

Ale kto potrzebuje paniki, jeśli możesz używać GDB w jądrze? Jeśli jesteś hardcorowy, spójrz na:

• QEMU lub inne maszyny wirtualne: https://stackoverflow.com/a/42316607/895245
• JTAG

Każdy problem spada, gdy masz pełną widoczność (i wystarczająco dużo czasu!).