Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

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

ABRT は、多くの異なるプログラミング言語で書かれたアプリケーションにおけるクラッシュを検出、分析、プロセスできます。様々なタイプのクラッシュ検出のサポートを含むパッケージの多くは、ABRT の主要パッケージのいずれか (abrt-desktopabrt-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 ) から mapslimitscgroupstatus の各ファイルを保存します。これらのファイルのフォーマットおよび意味は、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 2 メニューのカーネルオプション一覧の crashkernel パラメーターを指定することで実行できます。kdump の有効化と設定の詳細は『Red Hat Enterprise Linux 7 カーネルクラッシュダンプガイド』 を参照してください。GRUB 2 メニューの変更方法は 25章GRUB 2 での作業 を参照してください。
abrt-pstoreoops サービスを使用すると、ABRT はカーネルパニックの情報を収集し、処理できるようになります。これは、pstore 対応のシステムでは、自動マウントされた /sys/fs/pstore/ ディレクトリーに保存されます。このプラットフォームに依存した pstore インターフェース (永続的なストレージ) は、システムの再起動時にデータを保存するメカニズムを提供するため、カーネルパニック情報の保存を可能にします。このサービスは、/sys/fs/pstore/ ディレクトリーにカーネルのクラッシュダンプファイルが現れると、自動的に起動します。