25.3. ABRT の設定
ABRT では、問題のライフサイクルは events によって決定されます。以下に例を示します。
- イベント 1 - 問題データのディレクトリー作成
- イベント 2: 問題データの分析
- イベント 3 - 問題の Bugzilla 報告
問題が検出されると、ABRT はその問題を既存の問題データと比較し、同じ問題が記録されているかどうかを確認します。記録されている場合には、その既存の問題データが更新され、最新の (重複している) 問題は再度記録されません。問題が ABRT で認識されない場合は、problem-data directory (問題データディレクトリー) が作成されます。通常、問題データディレクトリーは、analyzer、architecture、coredump, cmdline、executable、kernel、os_release、reason, time、uid などのファイルから成ります。
backtrace などのその他のファイルは、問題の分析中に作成される場合があります。これは、使用する分析方法と設定によって異なります。これは、使用するアナライザーメソッドやその設定によって異なります。たとえば kernel ファイルには、クラッシュしたカーネルのバージョンが記録されます。
問題データディレクトリーが作成され、問題データが収集された後は、ABRT GUI またはコマンドラインの abrt-cli ユーティリティーを使用してその問題を処理できます。記録された問題の処理に関する ABRT ツールの詳細は、「検出された問題の処理」 を参照してください。
25.3.1. イベントの設定
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/ ディレクトリーにファイルをコピーして、コピーしたファイルを修正してください。これらのファイルには、以下の情報が含まれています。
- ユーザーフレンドリーのイベント名および説明 (Bugzilla、Bugzilla バグトラッカーへのレポート)
- イベントが正常に実行されるために必要な問題データディレクトリー内のアイテムリスト
- 送信するおよび送信しないデフォルトおよび必須の選択アイテム
- GUI がデータ見直しを要求するかどうか
- 存在する設定オプション、そのタイプ (文字列、ブール値など)、デフォルト値、プロンプト文字列など。これらにより、GUI が適切な設定ダイアログを構築できます。
たとえば、report_Logger イベントは、出力ファイル名をパラメーターとして受け入れます。それぞれの event_name.xml ファイルを使用することで、ABRT GUI は、選択されたイベントに対してどのパラメーターを指定できるかを判断し、ユーザーはそれらのパラメーターの値を設定できるようになります。設定された値は、ABRT GUI で保存され、イベントが後で呼び出される際に再利用されます。ABRT GUI は GNOME Keyring ツールを使用して設定オプションを保存し、これらをイベントに渡すことでテキスト設定ファイルからデータを上書きすることに注意してください。
グラフィカルの Configuration ウィンドウを開くには、実行中の gnome-abrt アプリケーションのインスタンスから
図25.1 ABRT イベントの設定
/etc/libreport/ ディレクトリー階層内のファイルはすべて、全ユーザーが読み取り可能となっており、グローバル設定として使用するためにあります。このため、ユーザー名、パスワード、その他の機密データは、これらのファイル内に保存しないことが推奨されます。ユーザー別の設定 (GUI アプリケーションで設定され、$HOME の所有者のみが読み取り可能) は、GNOME Keyring に安全に保管されます。または、abrt-cli で使用するには、$HOME/.abrt/ 内のテキスト設定ファイルに保管することもできます。
以下の表では、ABRT の標準インストールで提供される、デフォルトの分析、収集、レポートに関するイベントの一部を表示しています。ここでは、/etc/libreport/events.d/ ディレクトリーからの各イベントの名前、識別子、設定ファイルと簡単な説明をリスト表示しています。設定ファイルはイベント識別子を使用しますが、ABRT GUI では個別のイベント名が望ましいことに注意してください。また、GUI ではイベントの一部の設定は可能ではないことにも注意してください。カスタムイベントの定義方法に関する情報は、「カスタムイベントの作成」 を参照してください。
| 名前 | 識別子および設定ファイル | 詳細 |
|---|---|---|
| uReport | report_uReport | μReport を FAF サーバーにアップロードします。 |
| mailx | report_Mailx
| 問題レポートを Mailx ユーティリティーを介して指定のメールアドレスに送信します。 |
| Bugzilla | report_Bugzilla
| 問題を Bugzilla バグトラッカーの指定インストールにレポートします。 |
| Red Hat Customer Support | report_RHTSupport
| 問題を Red Hat テクニカルサポートシステムに報告します。 |
| Analyze C/C++ Crash | analyze_CCpp
| コアダンプをリモートの retrace サーバーに送信して分析します。または、リモート分析が失敗した場合は、ローカルの分析を実行します。 |
| Report uploader | report_Uploader
|
|
| VM コアの分析 | analyze_VMcore
|
カーネル oops の問題データに対して GDB (GNU Debugger) を実行し、カーネルの |
| Local GNU Debugger | analyze_LocalGDB
|
アプリケーションの問題データに対して GDB (GNU Debugger) を実行し、問題の |
| Collect .xsession-errors | analyze_xsession_errors
|
|
| ロガー | report_Logger
| 問題レポートを作成して、指定のローカルファイルに保存します。 |
| Kerneloops.org | report_Kerneloops
| カーネルの問題を kerneloops.org の oops トラッカーに送信します。 |
25.3.2. カスタムイベントの作成
各イベントは、それぞれの設定ファイル内の単一のルール構造により定義されます。これらの設定ファイルは、通常 /etc/libreport/events.d/ ディレクトリーに格納されます。これらの設定ファイルは、メインの設定ファイル /etc/libreport/report_event.conf によりロードされます。abrt は /etc/libreport/events.d/ に含まれているスクリプトを実行するため、デフォルトの設定ファイルは編集する必要がありません。このファイルはシェルのメタ文字 (*、$、? など) を受け入れ、その位置に対する相対パスを解釈します。
各 ルール は、空白でない先頭文字の行で始まり、その後のすべての行は 空白 文字または タブ 文字で始まるすべての後続の行は、このルールの一部と見なされます。各ルールは、条件部分とプログラム部分の 2 つの部分で設定されています。条件パートには、以下のいずれかの形式で条件が記載されます。
- VAR=VAL
- VAR!=VAL
- VAL~=REGEX
詳細は以下のようになります。
-
VAR は、EVENT のキーワードまたは問題データディレクトリーの要素の名前です (
executable、package、hostnameなど)。 - VAL は、イベントまたは問題データの要素名です。
- REGEX は正規表現です。
プログラムパートは、プログラム名とシェルが解釈可能なコードで設定されます。条件パートにある全条件が有効な場合、プログラムパートがシェルで実行されます。以下は イベント の一例です。
EVENT=post-create date > /tmp/dt
echo $HOSTNAME uname -r
このイベントは、現在の日付と時刻で /tmp/dt ファイルの内容を上書きし、マシンのホスト名とカーネルバージョンを標準出力に表示します。
より複雑なイベント (実際の事前設定済みイベントの一例) の例は以下のようになります。このイベントは、abrt-ccpp サービスを使用して処理された問題の問題レポートに ~/.xsession-errors ファイルの関連する行を保存します。クラッシュ発生時点で、クラッシュしたアプリケーションに 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 の標準インストールでは、以下のイベント名が提供されています。
post-create-
このイベントは、
abrtdにより、新規に作成された問題データディレクトリーを処理するために実行されます。post-createイベントが実行すると、abrtdは、新規の問題データが既存の問題ディレクトリーと一致するかどうかを確認します。一致する問題ディレクトリーがある場合には、それが更新され、新規の問題データは破棄されます。post-createの定義内にスクリプトがゼロ以外の値で存在する場合、abrtdはプロセスを終了し、問題データが破棄されることに注意してください。 notify、notify-dup-
notifyイベントは、post-createの完了後に実行されます。このイベントが実行すると、問題に注意する必要があることをユーザーが確認できます。notify-dupも同様ですが、これは同一問題が重複して発生した場合に使用されます。 analyze_name_suffix-
ここでの name_suffix は、イベント名の置き換え可能な部分です。このイベントは、収集データの処理に使用されます。たとえば、
analyze_LocalGDBは GNU Debugger (GDB) ユーティリティー使用してアプリケーションのコアダンプを処理し、クラッシュのバックトレースを生成します。 collect_name_suffix{blank}ここでの name_suffix は、イベント名の調整可能な部分です。このイベントは、問題に関する追加情報を収集するために使用されます。
report_name_suffix{blank}ここでの name_suffix は、イベント名の調整可能な部分です。このイベントは、問題を報告するために使用されます。
25.3.3. 自動レポーティングの設定
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 アプリケーションの実行中のインスタンス内で
図25.2 ABRT 問題報告ツールの設定
デフォルトでは、ABRT はクラッシュを検出すると、問題の基本情報を含む μReport を Red Hat の ABRT サーバーに提出します。サーバーは問題が既知のものかどうかを判断し、既知の場合はそのケースの URL と問題の簡単な説明を提供します。既知でない場合は、ユーザーに報告するように促します。
μReport (マイクロレポート) は、バイナリークラッシュやカーネル oops などの問題を表す JSON オブジェクトです。これらのレポートは、簡潔で、マシンが読み取ることができ、完全に匿名になるように設計されています。これが自動レポートに使用できる理由です。μReports を使用すると、バグの発生を追跡できます。ただし、通常はエンジニアがバグを修正するのに十分な情報を提供しません。サポートケースを作成するには、詳細なバグレポートが必要になります。
自動レポーティング機能の動作について、μReport の送信から別の動作に変更するには、/etc/abrt/abrt.conf 設定ファイルの AutoreportingEvent の値を別の ABRT 胃ベンドに変更します。標準イベントの概要は 表25.1「標準 ABRT イベント」 を参照してください。
