Кто разбивает мое ядро?

Question

симптомы

Внезапно после входа в систему после загрузки появилось сообщение "Проблема в пакете ядра". Новое сообщение отображается каждую секунду, непрерывно (перевод ниже).

Перевод:

О проблеме сообщили

Обнаружена проблема в пакете ядра

Я не знаю, что вызывает появление этих сообщений. Как мне получить подробную информацию о сбоях системы?

Спекуляции

Я не обновлял ядро в последние 12 дней (3.19.7-200.fc21.x86_64). Загрузка из старого ядра не останавливает предупреждения.

Сегодня я установил 5 новых пакетов: subversion-1.8.11-1.fc21.x86_64, gitk-2.1.0-4.fc21.noarch, git-gui-2.1.0-4.fc21.noarch, subversion-libs- 1.8.11-1.fc21.x86_64 и libserf-1.3.7-2.fc21.x86_64

Я установил несколько расширений gnome, но без перезагрузки использовал их несколько часов. Я отключил расширения и проблема сохраняется.

Что я пробовал

Я считаю, что эти уведомления являются частью abrt . Но когда я попытался получить более подробную информацию, abrt-cli list ничего не показывает за текущий месяц.

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

Как предложено в комментарии, я проверил /var/log/messages , /var/log/syslog и /var/log/kern.log:

Последние два нет. tail /var/log/messages содержит много (более тысячи) следующих, повторяющихся снова и снова (с разными временными метками):

May 26 16:39:28 [hostname] abrt-dump-journal-oops: Reported 1 kernel oopses to Abrt
May 26 16:39:30 [hostname] abrt-dump-journal-oops: abrt-dump-journal-oops: Found oopses: 1
May 26 16:39:30 [hostname] abrt-dump-journal-oops: abrt-dump-journal-oops: Creating problem directories
May 26 16:39:30 [hostname] abrt-server: Deleting problem directory oops-2015-05-26-16:39:30-585-0 (dup of oops-2015-04-28-15:49:00-21380-1)
May 26 16:39:30 [hostname] gnome-session: abrt-applet: repeated problem in kernel, not showing the notification

Проблема, обнаруженная в 2015-04-28-15:49:00 в abrt-cli list :

id dadaa8ca8525cf44b21c438b086cc731ac73c2cd
reason:         WARNING: CPU: 0 PID: 21350 at fs/block_dev.c:67 bdev_inode_switch_bdi+0x87/0x90()
time:           Ter 28 Abr 2015 15:49:02 BRT
cmdline:        BOOT_IMAGE=/boot/vmlinuz-3.19.3-100.fc20.x86_64 root=UUID=45f0c704-ada0-411d-95ba-50169ce0994a ro rd.md=0 rd.lvm=0 rd.dm=0 rd.luks=0 vconsole$
package:        kernel
count:          1529
Directory:  /var/tmp/abrt/oops-2015-04-28-15:49:00-21380-1
Relatado:   https://retrace.fedoraproject.org/faf/reports/bthash/392cacbf6958e88053298dbce758bf6865c4db3f

Answer 1

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

Есть несколько типов проблем, которые могут возникнуть в ядре.

• Предупреждение (WARN), ошибка (BUG) или OOPS могут возникать, когда встроенные самопроверки ядра обнаруживают ситуацию, которая может привести к нестабильности системы или потере данных в будущем. Однако, вообще говоря, эти проблемы не вызывают (немедленного) сбоя системы. Обычно OOPS являются наиболее серьезными из них и приводят к тому, что любые связанные процессы пользовательского пространства получают сигнал SIGKILL ("ты умрешь", а не «пожалуйста, уходи») от ядра.

• Паника - это то, когда система настолько взволнована, что отказывается продолжать. В этом случае ядро просто прекращает выполнение (после печати трассировки стека, если оно в состоянии это сделать) и передает управление… ничего. Обычно. Хотя, если у вас есть аварийное ядро, иногда поврежденное ядро будет пытаться загрузить второе ядро, целью которого является сбор информации о причине сбоя, и попытаться записать его на диск. В общем случае даже очень устойчивое аварийное ядро не может полностью восстановить состояние системы, чтобы оно могло быть снова работоспособным и стабильным без перезагрузки.

На мой взгляд, авария является синонимом паники. Есть много ситуаций, когда WARN или BUG могут быть безопасно проигнорированы, с очень низкой вероятностью потери данных. Если ваша система продолжает работать после сообщения об этих "проблемах", это почти наверняка не паника.

Вы не дали мне достаточно ваших журналов (в частности, dmesg), чтобы я мог определить причину этого конкретного сбоя, но в целом, когда само ядро сообщает о проблемах, оно будет проявляться в кольцевом буфере ядра dmesg . Буквально выполните команду dmesg на консоли, чтобы просмотреть кольцевой буфер ядра.

Похоже, что в вашем случае вы могли столкнуться с однократным опозданием, которое неправильно обрабатывается системой уведомлений о abrt (или инфраструктурой пользовательского интерфейса GNOME, которая отображает его вам).

26 мая 16:39:30 segtic-1c505e gnome-session: abrt-applet: повторяющаяся проблема в ядре, не отображается уведомление

Таким образом, он думает, что не показывает это вам, потому что это повторяющаяся проблема, но он продолжает бомбардировать вас той же ошибкой. Итак, либо abrt-applet думает, что он не бомбардирует вас, но на самом деле делает это в любом случае, либо есть другая программа, которая обрабатывает ошибки ядра (возможно, другой апплет, который также имеет дело с abrt?) это не обнаруживает повторяющихся проблем и отбрасывает вас одним и тем же снова и снова.

Итак, здесь есть несколько проблем:

1. Вы не дали мне никаких журналов dmesg которые указывают на повторяющуюся проблему. То, что вы показали в ACPI, может быть причиной одной ошибки, но это произошло очень рано при загрузке, и это не происходит снова и снова.

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

3. Очевидно, это вопрос , который вы испытываете какое - то авария или OOPS или BUG или WARN , связанный с ядром Linux в первую очередь. Но так как журналы ядра, которые вы разместили, были минимальными и не особенно касающимися, корень проблемы кажется неуловимым прямо сейчас. Если жалуется , что ACPI вопрос с начала загрузки, он должен действительно научиться заткнуться; Дело в том, что ACDI DSDT материнской платы почти всегда ужасно искажены и сломаны, и ОС просто нужно научиться справляться с этим как можно лучше. Вы ничего не можете с этим поделать как конечный пользователь. Не похоже, что ваш производитель mobo все еще будет выпускать обновления BIOS, чтобы попытаться улучшить свою корректность DSDT (ну, в любом случае, вряд ли они это сделают).

Или, может быть, проблема совершенно не связана с ACPI, а фактическое сообщение о проблеме просто не попадает в кольцевой буфер ядра. Это было бы довольно странно, и не то, что я испытал раньше. В этом отношении я не уверен, какой механизм abrt использует для обнаружения существования ошибки, если она не разбирает dmesg .

Когда дело доходит до проблем с ядром Linux и того, как они сообщаются в пользовательском интерфейсе, редко существует простой способ его диагностики. Это природа зверя.