Де є журнали паніки ядра?

У мене проблема з Handbrake / ffmpeg. Після ~ 5 хвилин перекодування комп'ютер блокується. Я впевнений, що це паніка з ядром, оскільки шапки-блокування починають блимати.

Є кілька логічних питань щодо того, що робити, і деякі конкретні помилки, але я дійсно після одного: що сталося прямо перед тим, як все померло ?!

Я перевірив /var/log/kern.log і все, що я бачу в цей час, я вставляю DVD, а потім через кілька хвилин система завантажується. Ні помилок, ні паніки.

Чи є спосіб змусити паніку реєструватися? Я досить впевнений, що можу це відтворити (це траплялося в 100% випадків, які я намагався останнім часом), тому хоча я вважаю за краще це "просто працювало", я щасливий перезавантажити кілька разів, якщо це означає, що я можу знайти причину паніки.

Всі ваші системні журнали в Ubuntu обробляється , rsyslogяка зберігає свою конфігурацію в /etc/rsyslog.confі/etc/rsyslog.d/ .

Для отримання додаткової інформації про налаштування rsyslogта можливі параметри відвідайте сторінку rsyslog.conf man page.

Відкривши, /etc/rsyslog.d/50-default.confви бачите, що один із рядків містить

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

Це означає, що файл, який ви шукаєте в цьому випадку, - це будь-який з величезних /var/log/syslogжурналів, які ви, мабуть, матимете.

Ви можете бачити, що ім'я файлу також починається з символу a -, це означає, що файл кешується перед записом, його чудово, але він може залишити вас поганим журналом, що ви хочете, це те, що журнал пишеться, як тільки виникає проблема. Вийміть тире і перезавантажте або перезавантажте, rsyslogа потім змусіть комп'ютер знову вийти з ладу, перевірте /var/log/syslog.

Якщо це справді паніка ядра, то вона не запишеться в журнал звичайними методами. Оскільки ядро ​​в цей момент вийшло з ладу, запис у файлову систему - це ризикована операція - не надто багато ядра можна більше довіряти, тому записування в журнали може насправді викликати випадкове лайно над вашим завантажувачем!

Натомість ви можете скинути вміст пам’яті у свій swap, а потім налагодити його. Це відоме як дамп збою / ядра ядра.

У Ubuntu Wiki є корисний рецепт CrashdumpRecipe - хоча він виглядає трохи застарілим, я не думаю, що надто багато чого слід було б змінити.

Серійний порт

Послідовний порт - це простий механізм зв'язку між комп'ютерами низького рівня.

Переваги:

• просте налаштування один раз (якщо у вас є обладнання)
• надійний, оскільки передача даних залежить лише від простого API проводів та ядра, на який менша ймовірність вплине паніка, ніж скажімо, підсистема TCP / IP.

Недоліки:

• Більшість сучасних ноутбуків більше не мають серійного порту (виставлений?), щоб заощадити місце. Але настільні та віртуальні машини все ще роблять.
• Вам також потрібен другий комп'ютер із послідовним портом, а також для отримання даних, але це стосується в основному всіх вбудованих плат розвитку, таких як Raspberry Pi.
• обмежена довжиною послідовного кабелю фізичного рівня, на відміну від мереж TCP / IP, які необмежені. Однак це можна вирішити за допомогою пристрою, який взаємодіє між послідовним і TCP / IP. Але є пристрої, які конвертують між собою.

Серійний порт виглядає приблизно так:

і на RPI доступний через GPIO.

Потім, якщо у вас є необхідне обладнання, підключіть з другого до основного комп'ютера за допомогою:

screen /dev/ttyS0 115200

Це фактично дає вам оболонку.

Потім на головній машині розпочніть операцію, яка панікує.

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

Інші методи

Існують також інші методи, які долають апаратні обмеження, згадані вище, ціною бути складнішими та менш надійними. Помітні методи:

• netdump: передає паніку через TCP / IP. Покладається на те, що підсистема TCP / IP не буде пошкоджена.
• kdump: як видається, лежить в основі механізму linux-crashdump, згаданий на веб- сайті: https://askubuntu.com/a/104793/52975 Запускає друге ядро ​​Linux для вивчення збіжного ядра. Що може піти не так ?! :-)

Дивіться також цю чудову відповідь: https://unix.stackexchange.com/questions/60574/determining- why-of-linux-kernel-panic

Крок налагодження

Зрештою, отримання панічного виводу вимагає, щоб якась функціональність ядра працювала, а будь-яка функціональність ядра могла бути пошкоджена панікою.

Але кому потрібна паніка, якщо ви можете використовувати GDB на ядрі? Якщо ви такий хардкор, подивіться на:

• QEMU або інші VM: https://stackoverflow.com/a/42316607/895245
• JTAG

Кожна проблема випадає, коли ви маєте повну видимість (і достатньо часу!).