25.4. ソフトウェア問題の検出

abrt-ccpp サービスは独自のコアダンプハンドラーをインストールします。これにより、起動時にカーネルの core_pattern 変数のデフォルト値が上書きされ、C および C++ のクラッシュが abrtd によって処理されます。abrt-ccpp サービスを停止すると、指定さてある core_pattern の値が回復します。

デフォルトでは、/proc/sys/kernel/core_pattern ファイルは core 文字列を格納しています。これは、カーネルが、クラッシュしたプロセスの現在のディレクトリーにおける core. 接頭辞のあるファイルを生成することを意味しています。abrt-ccpp サービスは core_pattern ファイルを上書きして、以下のコマンドを格納します。

|/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e

|/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e

このコマンドは、カーネルがコアダンプを abrt-hook-ccpp プログラムにパイプ処理するように指示します。これにより、ABRT のダンプの場所に格納され、新しいクラッシュについて abrtd デーモンに通知します。また、/proc/PID/ ディレクトリー (PID はクラッシュしたプロセスの ID の両方) から以下のファイルをデバッグ目的で格納します。maps、limits、cgroup、status。これらのファイルのフォーマットおよび意味は、proc(5) を参照してください。

abrt-addon-python パッケージは、Python アプリケーション用のカスタム例外ハンドラーをインストールします。次に Python インタープリターは、/usr/lib64/python2.7/site-packages/ にインストール済みの abrt.pth ファイルを自動的にインポートします。これにより、abrt_exception_handler.py がインポートされます。これにより、Python のデフォルトの sys.excepthook とカスタムハンドラーによる sys.excepthook が上書きされ、処理されていない例外がそのソケット API 経由で abrtd に転送されます。

サイト固有のモジュールの自動インポートを無効にして、Python アプリケーション実行時に ABRT カスタム例外ハンドラーが使用されないようにするには、Python インタープリターに -S オプションを渡します。

python -S file.py

~]$ python -S file.py

このコマンドでは、file.py を、サイト固有のモジュールを使用せずに実行する Python スクリプトの名前で置き換えます。

rubygem-abrt パッケージは、プログラムが終了したときに熟考される、at_exit 機能を使用するカスタムハンドラーを登録します。これは、プログラムの終了時に実行します。処理されていない例外が捕捉されるたびに、ABRT ハンドラーはバグレポートを作成します。これは標準の ABRT ツールを使用して Red Hat Bugzilla に提出することができます。

ABRT Java コネクターは、捕捉されなかった Java 例外を abrtd. にレポートする JVM エージェントです。エージェントは複数の JVMTI イベントコールバックを登録し、-agentlib コマンドラインパラメーターを指定して JVM にロードする必要があります。コマンドラインパラメーターを使用して JVM に読み込む必要があります。ABRT が Java クラスから例外を取得できるようにするには、以下のコマンドを使用します。

java -agentlib:abrt-java-connector=abrt=on $MyClass -platform.jvmtiSupported true

~]$ java -agentlib:abrt-java-connector=abrt=on $MyClass -platform.jvmtiSupported true

ここでは、$MyClass を、テストする Java クラス名に置き換えます。abrt=on オプションをコネクターに渡すと、例外が abrtd によって処理されるようになります。コネクターが標準出力の例外を出力する場合は、このオプションを省略します。

abrt-xorg は、X.Org server のクラッシュ情報を /var/log/Xorg.0.log ファイルから収集して処理します。ブラックリスト化された X.org モジュールが読み込まれている場合は、レポートが生成されないことに注意してください。その代わりに該当する説明の付いた not-reportable ファイルが問題データディレクトリーに作成されます。問題となっているモジュールリストは、/etc/abrt/plugins/xorg.conf ファイルで確認できます。デフォルトでは、商用のグラフィックドライバーのモジュールのみがブラックリスト化されています。

カーネルログの出力をチェックすることで、ABRT は致命的ではない Linux カーネルの正常な動作からの逸脱であるカーネル oops を見つけ、これを処理できます。この機能は、abrt-oops サービスが提供します。

ABRT は、abrt-vmcore サービスを使用して、致命的で再起動を必要とする回復不可能なエラーであるカーネルパニックも検出して処理できます。このサービスは、vmcore ファイル (カーネルコアダンプ) が /var/crash/ ディレクトリーに表示される場合にのみ起動します。コアダンプファイルが見つかると、abrt-vmcore が新たな problem-data directory を /var/spool/abrt/ ディレクトリー内に作成し、作成されたディレクトリーにコアダンプファイルを移動します。/var/crash/ ディレクトリーを検索すると、このサービスは停止します。

ABRT がカーネルパニックを検出できるようにするには、システムで kdump サービスが有効になっている必要があります。kdump カーネル用に確保されたメモリー容量が正しく設定されている必要があります。これは、system-config-kdump グラフィカルツールを使用して設定することも、GRUB 2 メニューにあるカーネルオプションのリストに crashkernel パラメーターを指定して設定できます。kdump の有効化と設定の詳細は、Red Hat Enterprise Linux 7 カーネルクラッシュダンプガイド を参照してください。GRUB 2 メニューの変更方法は 26章GRUB 2 での作業 を参照してください。

ABRT は、abrt-pstoreoops サービスを使用して、pstore に対応するシステム上で、自動的にマウントされた /sys/fs/pstore/ ディレクトリーに保存されているカーネルパニックの情報を収集および処理できます。これは、pstore 対応のシステムでは、自動マウントされた /sys/fs/pstore/ ディレクトリーに保存されます。そのため、カーネルパニック情報を保持することができます。このサービスは、/sys/fs/pstore/ ディレクトリーにカーネルのクラッシュダンプファイルが現れると、自動的に起動します。