Ядро Panic не выдает файлы журналов

Я играл в игру в Steam, и внезапно я испытал панику ядра. Я вручную выключил компьютер и загрузился обратно в 64-разрядную версию Linux Mint 17.1 (Cinnamon) и пошел проверять мои файлы журналов /var/log/, но не смог найти никаких ссылок или каких-либо сообщений, касающихся паники ядра, которые получилось.

Странно, почему он никогда не сбрасывал ядро ​​и даже не записывал его в файлы журнала. Как я могу убедиться, что ядро ​​всегда сбрасывается в случае повторения паники ядра? Не имеет никакого смысла, почему ничего не регистрировалось, когда произошла паника ядра. Осмотревшись на Google, люди предполагают , чтобы прочитать /var/log/dmesg, /var/log/syslog, /var/log/kern.log, и /var/log/Xorg.logт.д. ... но ничего. Даже в .Xsession-errorsфайле тоже.

Вот несколько фотографий экрана:

Я всегда мог сделать снимок экрана, когда и если это произойдет снова, но я просто хочу убедиться, что смогу заставить его сбросить ядро ​​и создать файл журнала при панике ядра.

Чтобы убедиться, что ваша машина генерирует файл «core» в случае сбоя ядра, вы должны подтвердить настройки «sysctl» вашей машины.

ИМО, следующие должны быть настройки (минимальные) в /etc/sysctl.conf:

kernel.core_pattern = /var/crash/core.%t.%p
kernel.panic=10
kernel.unknown_nmi_panic=1

Выполнить sysctl -pпосле внесения изменений в /etc/sysctl.confфайл. Возможно, вам следует также, mkdir /var/crashесли он еще не существует.

Вы можете проверить вышеописанное, сгенерировав ручной дамп с помощью SysRqключа (комбинация клавиш для дампа ядра - Alt+ SysRq+ C).

Когда ядро ​​паникует, это означает, что в ядре что-то пошло не так. Запись файлов журнала и дампов памяти требует использования драйверов для блочного устройства хранения (вашего диска) и файловой системы (должно быть выделено место и размер файла журнала должен быть обновлен). Учитывая, что те сервисы, которые предоставляются ядром, необходимы для записи файлов, и ядро ​​знает, что оно в поврежденном состоянии, оно не может записывать файлы или регистрировать что-либо, потому что оно больше не находится в безопасном состоянии, поэтому любая операция может ухудшить ситуацию и повредить / уничтожить вашу файловую систему. Таким образом, вы не можете заставить ядро ​​записывать в журнал или сбрасывать дамп ядра, когда он паникует.

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

Посмотрите, например, опцию crashkernel в Kernel Crash Dump на ubuntu.com. (Обратите внимание, что на этой странице написано, что механизм аварийного дампа ядра включен по умолчанию, начиная с Ubuntu 16.04.)

Я полагаю, что система на самом деле сохраняет дамп в зарезервированный кусок памяти, а затем перезагружается, и ядро ​​сохраняет зарезервированную память на диск при следующей загрузке (поскольку вновь загружаемое ядро ​​находится в нормальном состоянии и может это делать).