Где находятся журналы паники ядра?

Question 1

У меня проблема с ручным тормозом / ffmpeg. После ~ 5 минут транскодирования компьютер зависает. Я уверен, что это паника ядра, потому что caps-lock начинает мигать.

Есть несколько логических вопросов о том, что делать, а некоторые о конкретных ошибках, но я действительно хочу сказать одно: что произошло прямо перед тем, как все умерло?!

У меня есть проверил /var/log/kern.log, и все, что я вижу в это время, это то, что я вставляю DVD, а затем, через несколько минут, система загружается. Без ошибок, без паники.

Есть ли способ заставить панику регистрироваться? Я вполне уверен, что могу воспроизвести это (это случалось 100% раз, когда я пытался в последнее время), поэтому, хотя я бы предпочел, чтобы это "просто сработало", я достаточно счастлив, чтобы перезагрузить несколько раз, если это означает, что я могу найти причину паники.

Question 2

Все ваши системные журналы в 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 журналы, которые у вас, вероятно, будут.

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

Question 3

Question 4

Если это действительно паника ядра, то она не будет записана в журнал обычными методами. Поскольку в этот момент ядро перестало работать, запись в файловую систему является рискованной операцией - больше нельзя доверять ядру, поэтому запись в журналы может фактически извергать случайный мусор через ваш загрузчик!

Вместо этого, Вы можете сбросить содержимое памяти в свой своп, а затем отладить его. Это называется сбой ядра / дамп ядра.

В Ubuntu Wiki есть CrashdumpRecipe , который может быть полезен - хотя он выглядит немного устаревшим, я не думаю, что слишком многое должно было измениться.

Question 5

Последовательный порт

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

Преимущества:

простая настройка один раз (если у вас есть оборудование)
надежная, поскольку передача данных зависит только от простых проводов и 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-cause-of-linux-kernel-panic [ 1127]

Пошаговая отладка

В конечном счете, для получения вывода о панике необходимо, чтобы работала какая-то функциональность ядра, и любая функциональность ядра могла быть повреждена паникой.

Но кому нужна паника, если вы можете использовать GDB в ядре? Если вы хардкор, посмотрите:

QEMU или другие виртуальные машины: https://stackoverflow.com/a/42316607/895245
JTAG

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

Bruno Pereira · Answer 1 · 14 July 2014 в 13:52