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

ABRT は、多くの異なるプログラミング言語で書かれたアプリケーションにおけるクラッシュを検出、分析、プロセスすることができます。様々なタイプのクラッシュ検出のサポートを含むパッケージの多くは、ABRT の主要パッケージのいずれか (abrt-desktop、abrt-cli) がインストールされる際に自動的にインストールされます。ABRT のインストール方法については、「ABRT のインストールとそのサービスの起動」 を参照してください。以下の表は、サポート対象のクラッシュタイプと対応パッケージを一覧表示したものです。

表24.2 サポート対象のプログラミング言語およびソフトウェアプロジェクト

言語/プロジェクトパッケージ
C または C++abrt-addon-ccpp
Pythonabrt-addon-python
Rubyrubygem-abrt
Javaabrt-java-connector
X.Orgabrt-addon-xorg
Linux (カーネル oops)abrt-addon-kerneloops
Linux (カーネルパニック)abrt-addon-vmcore
Linux (永続的なストレージ)abrt-addon-pstoreoops

24.4.1. C および C++ クラッシュの検出

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

24.4.2. Python 例外の検出

abrt-addon-python パッケージは、Python アプリケーション用のカスタム例外ハンドラーをインストールします。次に Python インタープリターは、/usr/lib64/python2.7/site-packages/ にインストール済みの abrt.pth ファイルを自動的にインポートします。このファイルは同様に、abrt_exception_handler.py をインポートします。これにより Python のデフォルトの sys.excepthook がカスタムハンドラーで上書きされ、未処理の例外がソケット API 経由で abrtd に転送されます。
サイト固有のモジュールの自動インポートを無効にして、Python アプリケーション実行時に ABRT カスタム例外ハンドラーが使われないようにするには、Python インタープリターに -S オプションを渡します。 
~]$ python -S file.py
このコマンドでは、file.py を、サイト固有のモジュールを使用せずに実行する Python スクリプトの名前で置き換えます。

24.4.3. Ruby 例外の検出

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

24.4.4. Java 例外の検出

ABRT Java コネクターは、取得されていない Java 例外を abrtd にレポートする JVM エージェントです。これは、いくつかの JVMTI イベントコールバックを登録します。またこれは -agentlib コマンドラインパラメーターを使って JVM に読み込む必要があります。登録済みコールバックの処理は、アプリケーションのパフォーマンスにマイナスの影響を与えることに注意してください。ABRT が Java クラスから例外を取得できるようにするには、以下のコマンドを使用します。 
~]$ java -agentlib:abrt-java-connector[=abrt=on] $MyClass -platform.jvmtiSupported true
ここでは $MyClass をテストする Java クラス名に置き換えます。abrt=on オプションをコネクターに渡すことで、例外が abrtd に処理されるようになります。コネクターに例外を標準出力に出力させるには、このオプションを省略します。

24.4.5. X.Org クラッシュの検出

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

24.4.6. カーネル Oops およびカーネルパニックの検出

カーネルログの出力をチェックすることで、ABRT は致命的でない Linux カーネルの正常な動作からの逸脱であるカーネル oops を見つけ、これを処理することができます。この機能は、abrt-oops サービスが提供します。
ABRT は、abrt-vmcore サービスを使って、致命的で再起動を必要とする回復不可能なエラーであるカーネルパニックも検出して処理することができます。このサービスは、vmcore ファイル (カーネルコアダンプ) が /var/crash/ ディレクトリーに表示される場合にのみ起動します。コアダンプファイルが見つかると、abrt-vmcore が新たな problem-data directory を /var/tmp/abrt/ ディレクトリー内に作成し、コアダンプファイルをこの新規に作成された問題データディレクトリーに移動します。/var/crash/ ディレクトリーの検索後に、このサービスは停止します。
ABRT がカーネルパニックを検出できるようにするには、kdump サービスがシステム上で有効になっている必要があります。kdump カーネル用に確保されたメモリー容量が正しく設定されている必要があります。この設定は、 system-config-kdump グラフィカルツールを使うか、または GRUB メニューのカーネルオプション一覧の crashkernel パラメーターを指定することで実行できます。kdump の有効化と設定の詳細については、Red Hat Enterprise Linux 7 カーネルクラッシュダンプガイド を参照してください。GRUB メニューの変更方法については、 25章GRUB 2 での作業 を参照してください。
abrt-pstoreoops サービスを使うと、ABRT はカーネルパニックについての情報を収集し、処理できるようになります。これは、pstore 対応のシステムでは、自動マウントされた /sys/fs/pstore/ ディレクトリーに保存されます。このプラットフォームに依存した pstore インターフェース (永続的なストレージ) は、システムの再起動時にデータを保存するメカニズムを提供するため、カーネルパニック情報の保存を可能にします。このサービスは、/sys/fs/pstore/ ディレクトリーにカーネルのクラッシュダンプファイルが現れると、自動的に起動します。