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

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

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

Я проверил, /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.

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

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

В 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-cause-of-linux-kernel-panic

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

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

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

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

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