24.3. ABRT の設定

ABRT では、問題のライフサイクルは イベント によって決定されます。例を示します。
  • イベント 1 - 問題データのディレクトリー作成
  • イベント 2 - 問題データの分析
  • イベント 3 - 問題の Bugzilla 報告
問題が検出されると、ABRT はその問題を既存の問題データと比較し、同じ問題が記録されているかどうかを確認します。記録されている場合には、その既存の問題データが更新され、最新の (重複している) 問題は再度記録されません。問題が ABRT で認識されない場合は、problem-data directory (問題データディレクトリー) が作成されます。問題データディレクトリーは通常、analyzerarchitecturecoredumpcmdlineexecutablekernelos_releasereasontimeuid などのファイルで構成されます。
backtrace などのその他のファイルは、問題の分析中に作成される場合があります。これは、使用するアナライザーメソッドやその設定によって異なります。これらのファイルには、それぞれシステムおよび問題自体に関する固有の情報が格納されます。たとえば kernel ファイルには、クラッシュしたカーネルのバージョンが記録されます。
問題データディレクトリーが作成され、問題データが収集された後は、ABRT GUI またはコマンドラインの abrt-cli ユーティリティーを使ってその問題を処理できます。記録された問題の処理に関する ABRT ツールの詳細は、「検出された問題の処理」 を参照してください。

24.3.1. イベントの設定

ABRT のイベントは、プラグイン を使用して実際のレポーティング操作を行います。プラグインはコンパクトなユーティリティーで、イベントが、問題データディレクトリーのコンテンツを処理するために呼び出します。プラグインを使用することで、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 アプリケーションのインスタンスから Automatic Bug Reporting ToolPreferences (設定) を選択します。このウィンドウでは、GUI 使用したレポーティングのプロセス時に選択可能な全イベントが表示されます。設定可能なイベントを選択すると、Configure ボタンがクリックできる状態となり、そのイベントの設定値を修正できます。
ABRT イベントの設定

図24.1 ABRT イベントの設定

重要

/etc/libreport/ ディレクトリー階層内のファイルはすべて、全ユーザーが読み取り可能となっており、グローバル設定として使用するためにあります。このため、ユーザー名、パスワード、その他の機密データは、これらのファイル内に保存しないことが推奨されます。ユーザー別の設定 (GUI アプリケーションで設定され、$HOME の所有者のみが読み取り可能) は、GNOME Keyring に安全に保管されます。または、abrt-cli で使用するには、$HOME/.abrt/ 内のテキスト設定ファイルに保管することもできます。
以下の表では、ABRT の標準インストールで提供される、デフォルトの分析、収集、レポートに関するイベントの一部を表示しています。ここでは、/etc/libreport/events.d/ ディレクトリーからの各イベントの名前、識別子、設定ファイルと簡単な説明を一覧表示しています。設定ファイルはイベント識別子を使用しますが、ABRT GUI では個別のイベント名が望ましいことに注意してください。また、GUI ではイベントの一部の設定は可能ではないことにも注意してください。カスタムイベントの定義方法に関する情報は、「カスタムイベントの作成」 を参照してください。

表24.1 標準 ABRT イベント

名前識別子および設定ファイル詳細
uReport
report_uReport
 
μReport を FAF サーバーにアップロードします。
Mailx
report_Mailx
mailx_event.conf
問題レポートを Mailx ユーティリティーを介して指定のメールアドレスに送信します。
Bugzilla
report_Bugzilla
bugzilla_event.conf
問題を Bugzilla バグトラッカーの指定インストールにレポートします。
Red Hat Customer Support
report_RHTSupport
rhtsupport_event.conf
問題を Red Hat テクニカルサポートシステムに報告します。
Analyze C/C++ Crash
analyze_CCpp
ccpp_event.conf
コアダンプをリモートの retrace サーバーに送信して分析します。または、リモート分析が失敗した場合は、ローカルの分析を実行します。
Report uploader
report_Uploader
uploader_event.conf
FTP または SCP プロトコルを使用して、問題データの tarball (.tar.gz) アーカイブを、選択した宛先にアップロードします。
Analyze VM core
analyze_VMcore
vmcore_event.conf
カーネル oops の問題データに対して GDB (GNU Debugger) を実行し、カーネルの backtrace を生成します。
Local GNU Debugger
analyze_LocalGDB
ccpp_event.conf
アプリケーションの問題データに対して GDB (GNU Debugger) を実行し、問題の backtrace を生成します。
Collect .xsession-errors
analyze_xsession_errors
ccpp_event.conf
~/.xsession-errors ファイルから関連性のある行を問題レポートに保存します。
Logger
report_Logger
print_event.conf
問題レポートを作成して、指定のローカルファイルに保存します。
Kerneloops.org
report_Kerneloops
koops_event.conf
カーネルの問題を kerneloops.org の oops トラッカーに送信します。

24.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 のキーワードまたは問題データディレクトリーの要素の名前です (executablepackagehostname など)。
  • 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/ ディレクトリーに追加できます。
現在、ABRTlibreport の標準インストールでは、以下のイベント名が提供されています。
post-create
このイベントは、abrtd により、新規に作成された問題データディレクトリーを処理するために実行されます。post-create イベントが実行すると、abrtd は、新規の問題データが既存の問題ディレクトリーと一致するかどうかを確認します。一致する問題ディレクトリーがある場合には、それが更新され、新規の問題データは破棄されます。post-create の定義内にスクリプトがゼロ以外の値で存在する場合、abrtd はプロセスを終了し、問題データが破棄されることに注意してください。
notifynotify-dup
notify イベントは、post-create の完了後に実行されます。このイベントが実行すると、問題に注意する必要があることをユーザーが確認できます。notify-dup も同様ですが、これは同一問題が重複して発生した場合に使用されます。
analyze_name_suffix
ここでの name_suffix は、イベント名の置き換え可能な部分です。このイベントは、収集データの処理に使用されます。たとえば、analyze_LocalGDB は GNU Debugger (GDB) ユーティリティー使用してアプリケーションのコアダンプを処理し、クラッシュのバックトレースを生成します。
collect_name_suffix
ここでの name_suffix は、イベント名の調整可能な部分です。このイベントは、問題に関する追加情報を収集するために使用されます。
report_name_suffix
ここでの name_suffix は、イベント名の調整可能な部分です。このイベントは、問題を報告するために使用されます。

24.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 アプリケーションの実行中のインスタンス内で Automatic Bug Reporting ToolABRT Configuration を選択します。このアプリケーションを起動するには、アプリケーション諸ツール自動バグ報告ツール (ABRT) に移動します。
ABRT 問題報告ツールの設定

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

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

注記

μReport (マイクロレポート) は、バイナリークラッシュやカーネル oops などの問題を表す JSON オブジェクトです。これらのレポートは、簡潔で、システム内部で使用でき、完全に匿名になるように設計されています。これらの特長があるために、これらのレポートを自動レポーティングで使用できます。μReports を使用してバグの発生を追跡することはできますが、通常はエンジニアがバグを修正するのに必要な情報は十分に提供されません。サポートケースを作成するには、詳細なバグレポートが必要になります。
自動レポーティング機能の動作について、μReport の送信から別の動作に変更するには、/etc/abrt/abrt.conf 設定ファイルの AutoreportingEvent ディレクティブの値を別の ABRT イベントに向けるように修正する必要があります。標準イベントの概要は 表24.1「標準 ABRT イベント」 を参照してください。