У меня проблема с ручным тормозом / 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, который может быть полезен - хотя он выглядит немного устаревшим, я не думаю, что слишком многое должно было измениться.
источник
linux-crashdump; этот пакет по-прежнему доступен во всех версиях.Последовательный порт
Последовательный порт - это простой низкоуровневый механизм связи между компьютерами.
Преимущества:
Недостатки:
Последовательный порт выглядит так:
и на RPI доступен через GPIO.
Затем, если у вас есть необходимое оборудование, подключитесь со второго компьютера к основному компьютеру с помощью:
Это на самом деле дает вам оболочку.
Затем на главном компьютере запустите операцию, которая паникует.
Когда возникает паника, дамп паники перенаправляется на второй компьютер, и вы можете увидеть все это, прокрутив вверх по терминалу.
Другие методы
Существуют также другие методы, которые преодолевают аппаратные ограничения, упомянутые выше, за счет того, что они являются более сложными и менее надежными. Известные методы:
Смотрите также этот отличный ответ: https://unix.stackexchange.com/questions/60574/determining-cause-of-linux-kernel-panic
Пошаговая отладка
В конечном счете, получение вывода о панике требует, чтобы некоторые функциональные возможности ядра работали, и любая функциональность ядра могла быть повреждена паникой.
Но кому нужна паника, если вы можете использовать GDB в ядре? Если вы хардкор, взгляните на:
Каждая проблема падает, когда у вас есть полная видимость (и достаточно времени!).
источник