web-dev-qa-db-ja.com

誰が私のカーネルをクラッシュさせていますか？

症状

起動時にログインすると、突然「カーネルパッケージの問題を検出しました」というメッセージが表示され始めました。新しいメッセージが毎秒絶え間なく表示されます（以下の翻訳）。

enter image description here

翻訳：

問題が報告されました

カーネルパッケージの問題が検出されました

これらのメッセージが表示される原因がわかりません。システムクラッシュの詳細を取得するにはどうすればよいですか？

スペック

過去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をチェックしました。

後者の2つは存在しません。 tail /var/log/messagesには、次のたくさん（1000以上）が含まれ、（異なるタイムスタンプで）何度も繰り返されます：

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
linuxfedoracrashkernelfedora-21
4
That Brazilian Guy

まず第一に、あなたのカーネルはクラッシュではありません。クラッシュした場合、システムは完全にフリーズし、使用できなくなります。

カーネルで発生する可能性のある問題にはいくつかの種類があります。

  • 警告（警告）、バグ（バグ）または[〜＃〜]おっと[〜＃〜]カーネルが構築されたときに発生する可能性があります-セルフチェックでは、システムの不安定性や将来のデータの損失につながる可能性のある状況を検出します。ただし、一般的に言って、これらの問題はシステムの（即時の）クラッシュを引き起こしません。一般に、OOPSはこれらの中で最も深刻であり、関連するユーザースペースプロセスがカーネルからSIGKILL（「離れてください」ではなく「死ぬ」）信号を受信することになります。

  • パニックは、システムが非常にホースで接続されているため、続行を拒否する場所です。これは、カーネルが単に実行を停止し（スタックトレースを出力した後、実行できる場合）、制御を何も行わない場所です。通常。 クラッシュカーネルがある場合でも、壊れたカーネルは、クラッシュの原因に関する情報を収集することを目的とした2番目のカーネルをロードし、それをディスクに書き込もうとすることがあります。一般に、非常に堅牢なクラッシュカーネルでさえ、システムの状態を完全に回復して、再起動せずに再び使用可能で安定させることはできません。

私の考えでは、crashはpanicと同義です。 WARNまたはBUGを安全に無視でき、データが失われる可能性が非常に低い状況は数多くあります。これらの「問題」が報告された後もシステムが実行し続ける場合、それはほぼ間違いなくパニックではありません。

この特定のクラッシュの理由を説明するのに十分なログ（特にdmesg）を私に提供していませんが、一般に、カーネル自体が問題を報告している場合は、 dmesgカーネルリングバッファ。文字通り、コンソールでコマンドdmesgを実行して、カーネルリングバッファを表示します。

あなたの場合、abrtクラッシュイベント通知システム（またはそれを表示するGNOMEユーザーインターフェイスインフラストラクチャ）によって誤って処理されている1回限りのエラーが発生した可能性があります。

5月26日16：39：30segtic-1c505e gnome-session：abrt-applet：カーネルで繰り返し問題が発生し、通知が表示されない

したがって、それはthinks繰り返しの問題であるため、表示されませんが、同じエラーで攻撃を続けます。したがって、どちらかabrt-appletthinksそれはあなたを攻撃していませんが、とにかく実際にそうしています、またはカーネルエラーを処理する別のプログラム（おそらくabrt？も処理する別のアプレット）が検出されません繰り返される問題と同じもので何度もあなたを非難しています。

したがって、ここにはいくつかの問題があります。

  1. 繰り返しの問題を示すdmesgログを私に与えていません。あなたが示したACPIのことは、oneエラーの原因である可能性がありますが、それは起動の非常に早い段階で発生し、何度も発生することはありません。

  2. エラー報告インフラストラクチャが壊れているようです。あるレベルでは、abrtknowsは同じイベント（または原因が同じである一連の独立したイベント）に対する繰り返しのメッセージだと思いますが、どういうわけか通知が届いていますとにかくシステムを介してあなたのUIに。

  3. 明らかに、Linuxカーネルに関連する何らかのクラッシュまたはOOPSまたはBUGまたはWARNが発生していることが問題ですそもそも。しかし、投稿したカーネルログは最小限であり、特に関係がないため、問題の根本は今のところわかりにくいようです。 is初期起動からのACPIの問題について不平を言っている場合は、実際にシャットダウンすることを学ぶ必要があります。事実、マザーボードのACPI DSDTはほとんどの場合、ひどく壊れて壊れており、OSはそれを可能な限り最善に処理することを学ぶ必要があります。エンドユーザーとしてそれについてあなたができることは何もありません。マザーボードの製造元が、DSDTの正確性を向上させるためにBIOSアップデートをリリースしているわけではありません（とにかく、そうなる可能性はほとんどありません）。

または、問題がACPIとはまったく関係がなく、実際の問題レポートがカーネルリングバッファに届いていない可能性があります。これは確かにかなり奇妙なものであり、私が以前に経験したことではありません。さらに言えば、abrtを解析していない場合に、エラーの存在を検出するためにdmesgがどのメカニズムを使用しているかはわかりません。

Linuxカーネルの問題とそれらがUIで報告される方法に関しては、それを診断するための簡単な方法はめったにありません。それは獣の性質です。

2
allquixotic