ABRT グラフィカルユーザーインターフェース は、デスクトップ環境での作業用の操作が容易なフロントエンドを提供します。root ユーザーで以下のコマンドを実行すると、必要なパッケージがインストールできます。

~]# yum install abrt-desktop

インストール時、グラフィカルデスクトップセッションの開始時に ABRT 通知アプレットが自動的に開始するように設定されます。ターミナルで以下のコマンドを発行すると、ABRT アプレットが実行中であることを確認できます。

~]$ ps -el | grep abrt-applet
0 S  500 2036 1824 0 80  0 - 61604 poll_s ?    00:00:00 abrt-applet

アプレットが実行していない場合には、以下のように abrt-applet プログラムを実行すると、現行のデスクトップセッションでアプレットを手動で起動できます。

~]$ abrt-applet &
[1] 2261

コマンドラインインターフェース は、ヘッドレスマシンやネットワーク接続されたリモートシステム、またはスクリプト内で役に立ちます。root ユーザーで以下のコマンドを実行すると、必要なパッケージがインストールできます。

~]# yum install abrt-cli

ABRT が検出するクラッシュに関するメール通知を受け取るには、libreport-plugin-mailx パッケージがインストール済みである必要があります。root で以下のコマンドを実行すると、このパッケージをインストールできます。

~]# yum install libreport-plugin-mailx

デフォルトでは、これで通知はローカルマシンの root ユーザーに送信されます。電子メールの宛先は /etc/libreport/plugins/mailx.conf ファイルで設定できます。

ログイン時にコンソールに通知を表示するには、abrt-console-notification パッケージもインストールします。

ABRT では様々なタイプのソフトウェア障害を検出し、分析し、報告できます。ABRT はデフォルトで、C および C++ のアプリケーションのクラッシュなど、最も一般的な障害のサポートと共にインストールされます。他のタイプの障害サポートは各パッケージで提供されます。たとえば、Java 言語で作成されたアプリケーションの例外を検出するサポートをインストールするには、root で以下のコマンドを実行します。

~]# yum install abrt-java-connector

ABRT がサポートする言語およびソフトウェアプロジェクトの一覧は、「ソフトウェア問題の検出」 を参照してください。このセクションには、様々なタイプの障害の検出を可能にする対応パッケージの一覧も含まれています。

この abrtd デーモンは、abrt ユーザーが /var/spool/abrt ディレクトリー内のファイルシステム操作のために存在する必要があります。abrt パッケージがインストールされたときに、UID と GID が 173 の abrt ユーザーが存在していない場合は自動的に作成されます。それ以外の場合は、abrt ユーザーを手動で作成できます。その場合、abrtd は特定の UID と GID を要求しないため、任意の UID と GID を選択できます。

abrtd デーモンは、ブート時に起動するように設定されています。以下のコマンドを使用すると、現在のステータスを確認できます。

~]$ systemctl is-active abrtd.service
active

systemctl が inactive または unknown を返す場合、デーモンは動作していません。以下のコマンドを root として入力すると、現在のセッションでデーモンを開始できます。

~]# systemctl start abrtd.service

同じコマンドを使用して、関連するエラー検出サービスの開始またはステータスチェックを行うことができます。たとえば、ABRT で C または C++ のクラッシュを検出したいときは、abrt-ccpp サービスが実行中であることを確認します。利用可能な ABRT 検出サービスと各パッケージの一覧は 「ソフトウェア問題の検出」 を参照してください。

カーネルパニックまたはカーネル oops が発生したときのみ開始する abrt-vmcore サービスと abrt-pstoreoops サービス以外の全 ABRT サービスは、各パッケージがインストールされていれば、システムの起動時に自動的に有効になり開始します。ABRT サービスは、10章systemd によるサービス管理 に説明されているとおり、systemctl ユーティリティーを使うことで無効または有効にできます。

ABRT が正常に機能することをテストするには、kill コマンドを使用して SEGV 信号を送信し、プロセスを終了します。たとえば、以下の方法で sleep プロセスを開始して、kill コマンドでそれを終了します。

~]$ sleep 100 &
[1] 2823
~]$ kill -s SIGSEGV 2823

ABRT は kill コマンドの実行直後にクラッシュを検出し、グラフィカルセッションが実行されている場合に、GUI 通知アプレットにより検出された問題がユーザーに通知されます。コマンドラインで、abrt-cli list コマンドを実行するか、/var/spool/abrt/ ディレクトリーに作成されたクラッシュダンプを調べることで、クラッシュが検出されていることを確認できます。検出されたクラッシュを処理する方法は、「検出された問題の処理」 を参照してください。

ABRT のイベントは、plugins を使用して実際のレポーティング操作を行います。プラグインは、問題データディレクトリーの内容を処理するイベント呼び出しを行うコンパクトなユーティリティーです。プラグインを使用することで、ABRT は問題を様々な宛先に報告できますが、多くの場合は、報告先について何らかの設定が必要になります。たとえば、Bugzilla では、ユーザー名とパスワード、および Bugzilla サービスのインスタンスを指す URL が必要になります。

設定な詳細の中にはデフォルト値を設定できるもの (Bugzilla URLなど) もありますが、設定できないもの (ユーザー名など) もあります。ABRT は、システム全体の設定、ユーザー固有の設定の /etc/libreport/events/ または$HOME/.cache/abrt/events/ ディレクトリーで、report_Bugzilla.conf などの設定ファイルでこの設定を検索します。設定ファイルには、ディレクティブと値のペアが含まれています。

このファイルは、イベントの実行と問題データディレクトリーの処理のために最小限必要なものです。gnome-abrt ツールと abrt-cli ツールはこれらのファイルから設定データを読み取り、実行するイベントにこれを渡します。

イベントに関する追加情報 (環境変数としてイベントに渡すことができるパラメーターの説明、名前、タイプ、その他の属性など) は、/usr/share/libreport/events/ ディレクトリーの event_name.xml ファイルに保存されています。このファイルは、ユーザーインターフェースをより使いやすくするために gnome-abrt および abrt-cli で使用されます。標準インストールを変更する場合以外に、このファイルは編集しないでください。編集する場合は、対象ファイルを /etc/libreport/events/ ディレクトリーにファイルをコピーして、コピーしたファイルを修正してください。これらのファイルには、以下の情報が含まれています。

たとえば、report_Loggerイベントは、出力ファイル名をパラメーターとして受け入れます。それぞれの event_name.xml ファイルを使用することで、ABRT GUI は、選択されたイベントに対してどのパラメーターを指定できるかを判断し、ユーザーはそれらのパラメーターの値を設定できるようになります。設定された値は、ABRT GUI で保存され、イベントが後で呼び出される際に再利用されます。ABRT GUI は GNOME Keyring ツールを使用して設定オプションを保存し、これらをイベントに渡すことでテキスト設定ファイルからデータを上書きすることに注意してください。

グラフィカルの Configuration ウィンドウを開くには、実行中の gnome-abrt アプリケーションのインスタンスから Automatic Bug Reporting Tool → → → Preferences → を選択します。このウィンドウでは、GUI 使用したレポーティングのプロセス時に選択可能な全イベントが表示されます。設定可能なイベントを選択すると、Configure ボタンがクリックできる状態となり、そのイベントの設定値を修正できます。

図25.1 ABRT イベントの設定

以下の表では、ABRT の標準インストールで提供される、デフォルトの分析、収集、レポートに関するイベントの一部を表示しています。ここでは、/etc/libreport/events.d/ ディレクトリーからの各イベントの名前、識別子、設定ファイルと簡単な説明を一覧表示しています。設定ファイルはイベント識別子を使用しますが、ABRT GUI では個別のイベント名が望ましいことに注意してください。また、GUI ではイベントの一部の設定は可能ではないことにも注意してください。カスタムイベントの定義方法に関する情報は、「カスタムイベントの作成」 を参照してください。

各イベントは、それぞれの設定ファイル内の単一のルール構造により定義されます。設定ファイルは通常、/etc/libreport/events.d/ ディレクトリーに保存されます。これらの設定ファイルは、メインの設定ファイル /etc/libreport/report_event.conf によりロードされます。abrt は /etc/libreport/events.d/ に含まれているスクリプトを実行するため、デフォルトの設定ファイルは編集する必要がありません。このファイルはシェルのメタ文字 (*、$、? など) を受け入れ、その位置に対する相対パスを解釈します。

各 ルール は、空白でない先頭文字の行で始まり、その後のすべての行は space 文字または tab 文字で始まるすべての後続の行は、このルールの一部と見なされます。各ルールは、条件部分とプログラム部分の2つの部分で構成されています。条件パートには、以下のいずれかの形式で条件が記載されます。

詳細は以下のようになります。

プログラムパートは、プログラム名とシェルが解釈可能なコードで構成されます。条件パートにある全条件が有効な場合、プログラムパートがシェルで実行されます。以下は イベント の一例です。

EVENT=post-create date > /tmp/dt
    echo $HOSTNAME uname -r

このイベントは、現在の日付と時刻で /tmp/dt ファイルの内容を上書きし、マシンのホスト名とカーネルバージョンを標準出力に表示します。

より複雑なイベント (実際の事前設定済みイベントの一例) の例は以下のようになります。このイベントは、~/.xsession-errors サービスを使用して処理された問題の問題レポートに abrt-ccpp ファイルの関連する行を保存します。クラッシュ発生時点で、クラッシュしたアプリケーションに X11 ライブラリーが読み込まれていることが条件になります。

EVENT=analyze_xsession_errors analyzer=CCpp dso_list~=./libX11.
    test -f ~/.xsession-errors || { echo "No ~/.xsession-errors"; exit 1; }
    test -r ~/.xsession-errors || { echo "Can't read ~/.xsession-errors"; exit 1; }
    executable=cat executable &&
    base_executable=${executable##*/} &&
    grep -F -e "$base_executable" ~/.xsession-errors | tail -999 >xsession_errors &&
    echo "Element 'xsession_errors' saved"

使用される可能性のあるイベントのセットは限定されていません。システム管理者は、必要に応じてイベントを /etc/libreport/events.d/ ディレクトリーに追加できます。

現在、ABRT と libreport の標準インストールでは、以下のイベント名が提供されています。

ABRT は、検出されたすべての問題またはクラッシュの最初の匿名レポート (μReports とも呼ぶ) をユーザーの対話なしに自動送信するように設定できます。自動レポーティングがオンになっていると、クラッシュ検出の直後に、通常クラッシュレポーティングプロセスの最初に送信される μReport が送信されます。これにより、同一クラッシュについてのサポートケースの重複を効果的に防ぐことができます。自動レポーティング機能を有効にするには、root で以下のコマンドを発行します。

~]# abrt-auto-reporting enabled

上記のコマンドは、/etc/abrt/abrt.conf 設定ファイルの AutoreportingEnabled ディレクティブを yes に設定します。このシステムワイドの設定は、システムの全ユーザーに適用されます。このオプションを有効にすると、グラフィカルデスクトップ環境でも自動レポーティングが有効になることに注意してください。ABRT GUI の自動レポーティングのみを有効にするには、Problem Reporting Configuration ウィンドウで Automatically send uReport オプションを YES に切り替えます。このウィンドウを開くには、gnome-abrt アプリケーションの実行中のインスタンス内で Automatic Bug Reporting Tool → → → ABRT Configuration → を選択します。アプリケーションを起動するには、Applications → → → Sundry → → Automatic Bug Reporting Tool → に移動します。

図25.2 ABRT 問題報告ツールの設定

デフォルトでは、ABRT はクラッシュを検出すると、問題の基本情報を含む μReport を Red Hat の ABRT サーバーに提出します。サーバーは問題が既知のものかどうかを判断し、既知の場合はそのケースの URL と問題の簡単な説明を提供します。既知でない場合は、ユーザーに報告するように促します。

自動レポーティング機能の動作について、μReport の送信から別の動作に変更するには、/etc/abrt/abrt.conf 設定ファイルの AutoreportingEvent ディレクティブの値を別の ABRT 胃ベンドに変更します。標準イベントの概要は 表25.1「標準 ABRT イベント」 を参照してください。

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) を参照してください。

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

このコマンドでは、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

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

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

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

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

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

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

コマンドライン環境では、abrt-console-notification パッケージがインストール済みであれば、ログイン時に新たなクラッシュがユーザーに通知されます。コンソールでの通知は、以下のようになります。

ABRT has detected 1 problem(s). For more info run: abrt-cli list --since 1398783164

検出された問題を表示するには、以下の abrt-cli list コマンドを入力します。

~]$ abrt-cli list
id 6734c6f1a1ed169500a7bfc8bd62aabaf039f9aa
Directory:   /var/tmp/abrt/ccpp-2014-04-21-09:47:51-3430
count:     1
executable:   /usr/bin/sleep
package:    coreutils-8.22-11.el7
time:      Mon 21 Apr 2014 09:47:51 AM EDT
uid:      1000
Run 'abrt-cli report /var/tmp/abrt/ccpp-2014-04-21-09:47:51-3430' for creating a case in Red Hat Customer Portal

abrt-cli list コマンドの出力で一覧表示されるクラッシュにはそれぞれ、一意の識別子と abrt-cli を使用した追加の操作に使用できるディレクトリーがあります。

特定の問題に関する情報のみを表示するには、abrt-cli info コマンドを使用します。

    abrt-cli info -d directory_or_id

list および info の各サブコマンドの使用時に表示する情報量を増やすには、-d (--detailed) オプションを渡します。これにより、既に生成されていれば、関連の backtrace ファイルを含む一覧の問題についての格納されているすべての情報が表示されます。

特定の問題を分析して報告するには、abrt-cli report コマンドを使用します。

    abrt-cli report directory_or_id

上記のコマンドを実行すると、Red Hat カスタマーサポートでサポートケースを作成するために必要なログイン情報の提供を求められます。次に、abrt-cli がレポートの内容を含むテキストエディターを開きます。これでレポート内容を確認でき、クラッシュを再現させるための指示やコメントを記入できます。さらに、バックトレースも確認するようにしてください。バックトレースは、問題報告イベントの設定によっては公開サーバーに送信され、誰でも見ることができる場合があります。

export VISUAL=emacs

レポートでの作業が終了したら、変更を保存してエディターを終了します。問題を Red Hat カスタマーサポートのデータベースに報告した場合には、問題のケースがデータベースに作成されます。この時点から、報告プロセスで指定したメールに問題の解決の進捗状況が通知されるようになります。また、問題のケース作成時に提供された URL や Red Hat サポートからのメールを使って問題ケースをモニタリングすることもできます。

特定の問題を報告したくないことが分かっている場合は、その問題を削除できます。問題を削除して、その情報が ABRT に保存されないようにするには、以下のコマンドを使用します。

    abrt-cli rm directory_or_id

特定の abrt-cli コマンドのヘルプを表示するには、--help オプションを指定します。

    abrt-cli command --help

ABRT デーモンは、問題レポートが作成されると常に D-Bus メッセージをブロードキャストします。グラフィカルデスクトップ環境で ABRT アプレットが実行中の場合は、アプレットがそのメッセージを取得し、デスクトップに通知ダイアログを表示します。このダイアログの Report ボタンをクリックすれば、ABRT GUI を開くことができます。また、Applications → → → Sundry Automatic Bug Reporting Tool メニュー項目を選択して ABRT GUI を開くこともできます。

別の方法では、以下のようにコマンドラインから ABRT GUI を実行することもできます。

~]$ gnome-abrt &

ABRT GUI ウィンドウは、検出された問題の一覧を表示します。各問題エントリーは、障害が発生したアプリケーション名、アプリケーションがクラッシュした理由、その問題が最後に発生した日付で構成されます。

図25.3 ABRT GUI

問題の詳細な説明にアクセスするには、問題レポートの行をダブルクリックするか、各問題の行を選択し、Report ボタンをクリックします。その後、指示に従い、問題の記述手順、分析の方法、およびその報告先を判断します。問題を破棄するには、Delete ボタンをクリックします。