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

1

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

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

Я проверил /var/log/kern.log и все, что я вижу в это время, - это то, что я вставляю DVD, а затем, через несколько минут, система загружается. Никаких ошибок, никаких предупреждений о панике.

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

2

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

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

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

3

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

4

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

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

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

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

Недостатки:

  • большинство современных ноутбуков больше не имеют последовательного порта (открытого?) для экономии места. Но настольные компьютеры и виртуальные машины по-прежнему работают.
  • вам также понадобится второй компьютер с последовательным портом для приема данных, но это относится практически ко всем встроенным платам разработки, таким как Raspberry Pi.
  • ограничена длиной последовательного кабеля физического уровня, в отличие от сетей TCP/IP, которые не ограничены. Однако это можно обойти, подключив устройство, которое преобразует между последовательным и TCP/IP в последовательный на удаленном компьютере

Последовательный порт выглядит следующим образом:

а на RPI доступен через GPIO, вот как это выглядит (с интерфейсом USB к ноутбуку на другой стороне):

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

Затем, если у вас есть необходимое оборудование, подключитесь со второго компьютера к основному компьютеру с помощью:

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

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

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

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

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

5

Какое-нибудь конкретное сообщение вы получаете при перекодировании? Может быть полезно для поиска решения :wink:

6

@Rinzwind Нет. Ничего не показывал, просто застыл.

7

Скорее всего, проблема с перегревом. Перекодирование сильно нагружает процессор, и если ваше охлаждение не будет эффективным на 100%, процессор перейдет в режим аварийного отключения. Я видел, как это происходило, например, когда термопаста высыхала на радиаторе процессора. Это также произошло, когда настройки разгона были перепутаны в BIOS. Попробуйте использовать xsensors для контроля температуры процессора непосредственно перед блокировкой.