第25章 自動バグ報告ツール (ABRT)

25.1. ABRT の概要

Automatic Bug Reporting Tool は通常 ABRT と呼ばれるツールセットで、ユーザーがアプリケーションクラッシュを検出し、報告する手助けとなるように設計されています。主な目的は、問題の報告と解決方法の発見のプロセスを容易にすることです。この場合の解決方法には、Bugzilla チケット、ナレッジベースの記事、修正を含むバージョンへの更新の提案などが含まれます。

ABRT は、abrtd デーモンと、検出された問題を処理、分析、および報告する多数のシステムサービスおよびユーティリティーで構成されます。デーモンは、アプリケーションがクラッシュしたりカーネルの Oop が検出されると、ほとんどの時間と Springs のバックグラウンドでサイレントに実行されます。次に、デーモンは、コアファイルがある場合にコアファイル、クラッシュアプリケーションのコマンドラインパラメーター、およびフォレンジックユーティリティーのその他のデータなど、関連する問題データを収集します。

ABRT は現在、C、C++、Java、Python、および Ruby プログラミング言語で書かれたアプリケーションにおけるクラッシュと、X.Org クラッシュ、カーネルの oops、およびカーネルパニックの検出をサポートしています。対応している障害やクラッシュのタイプの詳細や、さまざまなタイプのクラッシュが検出される仕組みは、「ソフトウェア問題の検出」 を参照してください。

特定された問題はリモートの問題トラッカーに報告され、このレポーティングは、問題が検出された際に自動的に報告されるように設定することが可能です。問題データは、ローカルまたは専用のシステムに保存して、ユーザーが手動でレビュー、報告、削除することも可能です。報告ツールは、Bugzilla データベースまたは Red Hat テクニカルサポート (RHTSupport) の Web サイトに問題データを送信できます。ツールは、FTP または SCP を使用してアップロードしたり、電子メールとして送信したり、ファイルに書き込んだりすることもできます。

既存の問題データを処理する ABRT コンポーネントは (新規の問題データの作成などとは対照的に)、libreport という別のプロジェクトの一部です。libreport ライブラリーは問題の分析および報告のための包括的メカニズムを提供し、ABRT 以外のアプリケーションでも使用されます。ただし、ABRT および libreport 操作と構成は密接に統合されています。したがって、それらはこのドキュメントの1つとして説明されています。

注記

ABRT レポートが生成されるのは、コアダンプが生成された時のみという点に注意してください。コアダンプは、一部のシグナル向けのみに生成されます。たとえば、SIGKILL (-9) はコアダンプを生成しないため、ABRT はこの失敗をキャッチできません。シグナルおよびコアダンプの生成に関する詳細は、man 7 シグナルを参照してください。

25.2. ABRT のインストールとサービスの起動

ABRT を使用するには、abrt-desktop または abrt-cli パッケージがシステムにインストールされていることを確認します。abrt-desktop パッケージは ABRT 用のグラフィカルユーザーインターフェースを提供し、abrt-cli パッケージにはコマンドラインで ABRT を使用するためのツールが含まれています。この両方をインストールすることもできます。ABRT GUI とコマンドラインツールのいずれを使用しても、全般的な手順は大きく変わりません。

警告

ABRT パッケージをインストールすると、コアダンプファイルの命名に使用するテンプレートを含む /proc/sys/kernel/core_pattern ファイルが上書きされることに注意してください。このファイルのコンテンツは、以下のように上書きされます。

|/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e

Yum パッケージマネージャーでパッケージをインストールする方法は 「パッケージのインストール」 を参照してください。

25.2.1. ABRT GUI のインストール

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

25.2.2. コマンドラインによる ABRT のインストール

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

~]# yum install abrt-cli

25.2.3. 補助 ABRT ツールのインストール

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

25.2.4. ABRT サービスの起動

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

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

~]$ systemctl is-active abrtd.service
active

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

~]# systemctl start abrtd.service

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

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

25.2.5. ABRT のクラッシュ検出テスト

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

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

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

25.3. ABRT の設定

ABRT では、問題のライフサイクルは events によって決定されます。以下に例を示します。

  • イベント 1 - 問題データのディレクトリー作成
  • イベント 2: 問題データの分析
  • イベント 3 - 問題の Bugzilla 報告

問題が検出されると、ABRT はその問題を既存の問題データと比較し、同じ問題が記録されているかどうかを確認します。記録されている場合には、その既存の問題データが更新され、最新の (重複している) 問題は再度記録されません。問題が ABRT で認識されない場合は、problem-data directory (問題データディレクトリー) が作成されます。問題のデータディレクトリーは、通常 analyzerarchitecturecoredumpcmdlineexecutablekernelos_releasereasontimeuid などのファイルで構成されます。

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 アプリケーションのインスタンスから Automatic Bug Reporting ToolPreferences を選択します。このウィンドウでは、GUI 使用したレポーティングのプロセス時に選択可能な全イベントが表示されます。設定可能なイベントを選択すると、Configure ボタンがクリックできる状態となり、そのイベントの設定値を修正できます。

図25.1 ABRT イベントの設定

ABRT GUIアプリケーションの構成ウィンドウのスクリーンショット。
重要

/etc/libreport/ ディレクトリー階層内のファイルはすべて、全ユーザーが読み取り可能となっており、グローバル設定として使用するためにあります。このため、ユーザー名、パスワード、その他の機密データは、これらのファイル内に保存しないことが推奨されます。ユーザー別の設定 (GUI アプリケーションで設定され、$HOME の所有者のみが読み取り可能) は、GNOME Keyring に安全に保管されます。または、abrt-cli で使用するには、$HOME/.abrt/ 内のテキスト設定ファイルに保管することもできます。

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

表25.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

.tar.gz または FTP プロトコルを使用して、問題データの tarball (SCP) アーカイブを、選択した宛先にアップロードします。

VM コアの分析

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 ファイルから問題のレポートに保存します。

ロガー

report_Logger

print_event.conf

問題レポートを作成して、指定のローカルファイルに保存します。

Kerneloops.org

report_Kerneloops

koops_event.conf

カーネルの問題を kerneloops.org の oops トラッカーに送信します。

25.3.2. カスタムイベントの作成

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

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

  • VAR=VAL
  • VAR!=VAL
  • VAL~=REGEX

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

  • VAR は、EVENT のキーワードまたは問題データディレクトリーの要素の名前です (executablepackagehostname など)。
  • VAL は、イベントまたは問題データの要素名です。
  • REGEX は正規表現です。

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

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/ ディレクトリーに追加できます。

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

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 アプリケーションの実行中のインスタンス内で Automatic Bug Reporting ToolABRT Configuration を選択します。アプリケーションを起動するには、ApplicationsSundryAutomatic Bug Reporting Tool に移動します。

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

ABRT GUIアプリケーションの構成ウィンドウのスクリーンショット。

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

注記

μReport (マイクロレポート) は、バイナリークラッシュやカーネル oops などの問題を表す JSON オブジェクトです。これらのレポートは、簡潔で、マシンが読み取ることができ、完全に匿名になるように設計されています。これが自動レポートに使用できる理由です。μReports を使用すると、バグの発生を追跡できます。ただし、通常はエンジニアがバグを修正するのに十分な情報を提供しません。サポートケースを作成するには、詳細なバグレポートが必要になります。

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

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

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

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

言語/プロジェクトパッケージ

C または C++

abrt-addon-ccpp

Python

abrt-addon-python

ruby

rubygem-abrt

Java

abrt-java-connector

X.Org

abrt-addon-xorg

Linux (カーネル oops)

abrt-addon-kerneloops

Linux (カーネルパニック)

abrt-addon-vmcore

Linux (永続的なストレージ)

abrt-addon-pstoreoops

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

25.4.2. Python 例外の検出

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 スクリプトの名前で置き換えます。

25.4.3. Ruby 例外の検出

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

25.4.4. Java 例外の検出

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 によって処理されるようになります。コネクターが標準出力の例外を出力する場合は、このオプションを省略します。

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

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

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

カーネルログの出力をチェックすることで、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/ ディレクトリーにカーネルのクラッシュダンプファイルが現れると、自動的に起動します。

25.5. 検出された問題の処理

abrtd で保存された問題データは、コマンドラインツール abrt-cli またはグラフィカルツール gnome-abrt を使用して表示し、報告し、削除することができます。

注記

ABRT は、新たな問題をローカルに保存されている全問題と比較することにより、問題の重複を特定することに注意してください。繰り返し発生しているクラッシュの場合、ABRT が対応を要求するのは 1 回のみです。ただし、この問題のクラッシュダンプを削除すると、次にこの問題が発生すると、ABRT はこれを新しいクラッシュとして扱います。ABRT は、ユーザーに警告を受け、説明を入力し、報告します。ABRT が繰り返し発生する問題の通知をしないようにするには、その問題データを削除しないようにしてください。

25.5.1. コマンドラインツールの使用

コマンドライン環境では、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 がレポートの内容を含むテキストエディターを開きます。これでレポート内容を確認でき、クラッシュを再現させるための指示やコメントを記入できます。さらに、バックトレースも確認するようにしてください。バックトレースは、問題報告イベントの設定によっては公開サーバーに送信され、誰でも見ることができる場合があります。

注記

レポートの確認に使用するテキストエディターを選択できます。abrt-cliABRT_EDITOR 環境変数で定義したエディターを使用します。変数が定義されていない場合は、VISUAL および EDITOR 変数を確認します。いずれの変数も設定されていない場合は、vi エディターが使用されます。.bashrc 設定ファイルで優先エディターを設定することもできます。たとえば、GNU Emacs を使用する場合は、このファイルに以下の行を追加します。

export VISUAL=emacs

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

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

    abrt-cli rm directory_or_id

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

    abrt-cli command --help

25.5.2. GUI の使用

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

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

~]$ gnome-abrt &

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

図25.3 ABRT GUI

ABRT GUI アプリケーションのスクリーンショット。

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

25.6. 関連資料

ABRT および関連トピックについての詳細情報は、以下に挙げるリソースを参照してください。

インストールされているドキュメント

  • abrtd(8): abrtd デーモンの man ページは、このデーモンと使用可能なオプションについての情報を提供します。
  • abrt_event.conf(5): abrt_event.conf 設定ファイルの man ページは、ディレクティブとルールのフォーマットを説明し、XML ファイル内のイベントメタデータ設定についての参照情報を提供します。

オンラインドキュメント

  • Red Hat Enterprise Linux 7 ネットワークガイド: Red Hat Enterprise Linux 7 の ネットワークガイド では、システム上のネットワークインターフェースおよびネットワークサービスの設定および管理に関する情報が説明されています。
  • Red Hat Enterprise Linux 7 カーネルクラッシュダンプガイド: Red Hat Enterprise Linux 7 の Kカーネルクラッシュガイドは、kdump クラッシュ回復サービスの設定し、テストし、使用する方法を説明します。また、それによって生じるコアダンプを crash デバッグユーティリティーで分析する方法の概要を説明します。

関連項目

  • 23章ログファイルの表示と管理 では、rsyslog デーモンと systemd ジャーナルの設定、およびシステムログの検索、表示、監視方法について説明しています。
  • 9章Yum では、Yum パッケージマネージャーを使って、コマンドラインでのパッケージの検索、インストール、更新、アンインストール方法について説明しています。
  • 10章systemd によるサービス管理 では、systemd の概説と、systemctl コマンドを使ったシステムサービスの管理方法、systemd ターゲットの設定方法、および電源管理コマンドの実行方法について説明しています。

このページには機械翻訳が使用されている場合があります (詳細はこちら)。