3.3. アプリケーションの相互作用の記録


アプリケーションの実行可能コードは、オペレーティングシステムや共有ライブラリーのコードと相互作用します。この相互作用のアクティビティーログを記録すると、実際のアプリケーションコードをデバッグしなくても、アプリケーションの動作を十分に把握できます。または、アプリケーションの相互作用を分析することで、バグが現れる条件を特定するのに役立ちます。

3.3.1. アプリケーションの相互作用の記録に役立つツール

Red Hat Enterprise Linux は、アプリケーションの相互作用を分析するための複数のツールを提供しています。

strace

strace ツールでは主に、アプリケーションが使用するシステムコール (カーネル関数) のロギングが可能になります。

  • strace がパラメーターを解釈し、基礎となるカーネルコードに関する知識が得られるため、strace ツールでは呼び出しに関する詳細な出力が得られます。数値は、定数名、フラグリストにデプロイメントされたビット単位の結合フラグ、実際の文字列を提供するために逆参照された文字配列へのポインターなどにそれぞれ変換されます。最新のカーネル機能のサポートがない場合があります。
  • トレースされた呼び出しをフィルタリングして、取得するデータ量を減らすことができます。
  • strace を使用する場合、ログフィルターの設定以外に特別なセットアップは必要ありません。
  • strace でアプリケーションコードを追跡すると、アプリケーションの実行速度が大幅に低下します。結果として、strace は、多くの実稼働環境のデプロイメントには適していません。代替方法として、ltrace または SystemTap の使用を検討してください。
  • Red Hat Developer Toolset で利用可能な strace のバージョンでは、システムコールの改ざんも実行できます。この機能は、デバッグに役立ちます。
ltrace

ltrace ツールを使用すると、アプリケーションのユーザー空間呼び出しのログを共有オブジェクト (動的ライブラリー) に記録できます。

  • ltrace ツールを使用すると、任意のライブラリーへの呼び出しを追跡できます。
  • トレースされた呼び出しをフィルタリングして、取得するデータ量を減らすことができます。
  • ltrace を使用するために、ログフィルターのセットアップ以外に、特別なセットアップは必要ありません。
  • ltrace ツールは軽量かつ高速で、strace に代わる機能を提供します。strace でカーネルの関数を追跡する代わりに、ltraceglibc など、ライブラリー内の各インターフェイスを追跡できます。
  • ltrace は、strace などの既知の呼び出しセットを処理しないため、ライブラリー関数に渡される値を説明しません。ltrace の出力には、raw の数値およびポインターのみが含まれます。ltrace の出力の解釈には、出力にあるライブラリーの実際のインターフェイス宣言を確認する必要があります。
注記

Red Hat Enterprise Linux 10 では、既知の問題により、ltrace がシステム実行可能ファイルをトレースできません。この制限は、ユーザーが構築する実行ファイルには適用されません。

SystemTap

SystemTap は、Linux システム上で実行中のプロセスおよびカーネルアクティビティーを調査するための有用なインストルメンテーションプラットフォームです。SystemTap は、独自のスクリプト言語を使用してカスタムイベントハンドラーをプログラミングします。

  • straceltrace を使用する場合と比較すると、ロギングのスクリプト化は、初期セットアップ段階での作業が増えることを意味します。ただし、スクリプト機能は単にログを生成するだけでなく、SystemTap の有用性を高めます。
  • SystemTap は、カーネルモジュールを作成し、挿入すると機能します。SystemTap は効率的に使用でき、システムまたはアプリケーションの実行速度が大幅に低下することはありません。
  • SystemTap には一連の使用例が提供されます。
GDB

GNU デバッガー (GDB) は主に、ロギングではなく、デバッグを目的としています。ただし、その機能の一部は、アプリケーションの相互作用が重要な主要なアクティビティーであるシナリオでも有用です。

  • GDB を使用すると、相互作用イベントを取得して、後続の実行パスの即時デバッグを簡単に組み合わせることができます。
  • GDB は、他のツールで問題のある状況を最初に特定した後、まれなイベントまたは特異なイベントへの応答を分析するのに最適です。イベントが頻繁に発生するシナリオで GDB を使用すると、効率が悪くなったり、不可能になったりします。

3.3.2. strace を使用したアプリケーションのシステムコールの監視

strace ツールを使用すると、アプリケーションによって実行されるシステム (カーネル) 呼び出しを監視できます。

手順

  1. 監視するシステムコールを特定します。

    • strace を起動して、プログラムに割り当てます。

      • 監視するプログラムが実行されていない場合は、strace を起動して、プログラム を指定します。

        $ strace -fvttTyy -s 256 -e trace=call program
        Copy to Clipboard Toggle word wrap
      • プログラムがすでに実行中の場合は、プロセス id (pid) を検索して、その id に strace を割り当てます。

        $ ps -C program
        (...)
        $ strace -fvttTyy -s 256 -e trace=call -ppid
        Copy to Clipboard Toggle word wrap
    • call は、表示するシステムコールに置き換えます。-e trace=call オプションは複数回使用できます。何も指定しない場合、strace はすべてのシステムコールタイプを表示します。詳細は、man ページの strace(1) を参照してください。
    • フォークされたプロセスまたはスレッドを追跡しない場合は、-f オプションを指定しないでください。
  2. strace ツールは、アプリケーションによるシステムコールとその詳細を表示します。

    ほとんどの場合、システムコールのフィルターが設定されていないと、アプリケーションとそのライブラリーは多数の呼び出しを行い、strace 出力がすぐに表示されます。

  3. プログラムが終了すると、strace ツールも終了します。

    追跡しているプログラムの終了前に監視を中断するには、Ctrl+C を押します。

    • strace でプログラムを起動すると、そのプログラムは strace と共に終了します。
    • 実行中のプログラムに strace を割り当てると、そのプログラムは strace と共に終了します。
  4. アプリケーションが実行したシステムコールのリストを分析します。

    • リソースへのアクセスや可用性の問題は、エラーを返す呼び出しとしてログに表示されます。
    • システムコールに渡される値とコールシーケンスのパターンは、アプリケーションの動作の原因に関する洞察を提供します。
    • アプリケーションがクラッシュした場合、重要な情報はおそらくログの最後にあります。
    • 出力には不要な情報が多く含まれています。ただし、目的のシステムコールに対してより正確なフィルターを作成し、この手順を繰り返すことができます。

      注記

      出力を確認することにも、ファイルに保存することにも利点があります。これを実行するには、tee コマンドを使用します。

      $ strace ... |& tee your_log_file.log
      Copy to Clipboard Toggle word wrap

3.3.3. ltrace を使用したアプリケーションのライブラリー関数呼び出しの監視

ltrace ツールを使用すると、ライブラリー (共有オブジェクト) で利用可能な関数へのアプリケーションの呼び出しを監視できます。

注記

Red Hat Enterprise Linux 10 では、既知の問題により、ltrace がシステム実行可能ファイルをトレースできません。この制限は、ユーザーが構築する実行ファイルには適用されません。

手順

  1. 可能であれば、対象のライブラリーおよび関数を特定します。
  2. ltrace を起動し、プログラムに割り当てます。

    • 監視するプログラムが実行されていない場合には、ltrace を起動して、プログラム を指定します。

      $ ltrace -f -l library -e function program
      Copy to Clipboard Toggle word wrap
    • プログラムがすでに実行中の場合は、プロセス id (pid) を検索して、その id に ltrace を割り当てます。

      $ ps -C program
      (...)
      $ ltrace -f -l library -e function -ppid program
      Copy to Clipboard Toggle word wrap
    • -e オプション、-f オプション、および -l オプションを使用して、出力にフィルターを設定します。

      • function として表示される関数の名前を指定します。-e function オプションは複数回使用できます。何も指定しないと、ltrace はすべての関数への呼び出しを表示します。
      • 関数を指定するのではなく、-l library オプションでライブラリー全体を指定することができます。このオプションは、-e function オプションと同じように動作します。
      • フォークされたプロセスまたはスレッドを追跡しない場合は、-f オプションを指定しないでください。

      詳細情報は、man ページの ltrace(1) を参照してください。

  3. ltrace は、アプリケーションによるライブラリー呼び出しを表示します。

    多くの場合は、フィルターが設定されていないと、アプリケーションは多数の呼び出しを行い、ltrace の出力がすぐに表示されます。

  4. ltrace は、プログラムが終了すると終了します。

    追跡しているプログラムの終了前に監視を中断するには、ctrl+C を押します。

    • ltrace でプログラムを起動した場合には、プログラムは ltrace と共に終了します。
    • 実行中のプログラムに ltrace を割り当てると、プログラムは ltrace と共に終了します。
  5. アプリケーションが実行したライブラリーコールのリストを分析します。

    • アプリケーションがクラッシュした場合、重要な情報はおそらくログの最後にあります。
    • 出力には不要な情報が多く含まれています。ただし、より正確なフィルターを作成して、手順を繰り返すことができます。
注記

出力を確認することにも、ファイルに保存することにも利点があります。これを実行するには、tee コマンドを使用します。

+

$ ltrace ... |& tee your_log_file.log
Copy to Clipboard Toggle word wrap

3.3.4. SystemTap を使用したアプリケーションのシステムコールの監視

SystemTap ツールでは、カーネルイベントにカスタムイベントハンドラーを登録できます。strace ツールと比較すると、使いにくいですが、より効率的で、より複雑な処理ロジックを可能にします。strace.stp と呼ばれる SystemTap スクリプトは、SystemTap と共にインストールされ、SystemTap を使用して strace に類似の機能を提供します。

手順

  1. 監視するプロセスのプロセス ID (pid) を検索します。

    $ ps -aux
    Copy to Clipboard Toggle word wrap
  2. strace.stp スクリプトで SystemTap を実行します。

    # stap /usr/share/systemtap/examples/process/strace.stp -x pid
    Copy to Clipboard Toggle word wrap

    pid の値は、プロセス ID です。

    スクリプトはカーネルモジュールにコンパイルされ、それが読み込まれます。これにより、コマンドの入力から出力の取得までにわずかな遅延が生じます。

  3. プロセスでシステムコールが実行されると、呼び出し名とパラメーターがターミナルに出力されます。
  4. プロセスが終了した場合、または Ctrl+C を押した場合に、スクリプトは終了します。

3.3.5. GDB を使用したアプリケーションのシステムコールの傍受

GNU Debugger (GDB) を使用すると、プログラム実行中に発生するさまざまな状況で実行を停止できます。プログラムがシステムコールを実行する時点で実行を停止するには、GDB の キャッチポイント を使用します。

手順

  1. キャッチポイントを設定します。

    (gdb) catch syscall syscall-name
    Copy to Clipboard Toggle word wrap

    catch syscall コマンドは、プログラムがシステムコールを実行する際に実行を停止する特別なタイプのブレークポイントを設定します。

    syscall-name オプションは、コールの名前を指定します。さまざまなシステムコールに対して複数のキャッチポイントを指定できます。syscall-name オプションに何も指定しない場合には、GDB はすべてのシステムコールで停止します。

  2. プログラムの実行を開始します。

    • プログラムにより、実行が開始していない場合は開始します。

      (gdb) r
      Copy to Clipboard Toggle word wrap
    • プログラムの実行が停止した場合は、再開します。

      (gdb) c
      Copy to Clipboard Toggle word wrap
  3. GDB は、プログラムが指定のシステムコールを実行した後に実行を停止します。
  4. その他の GDB コマンドを使用してプログラムの状態を調べ、状況に応じて実行を進めます。
  5. GDB デバッグセッションを終了するには、以下を実行します。

    (gdb) q
    Copy to Clipboard Toggle word wrap

3.3.6. GDB を使用したアプリケーションによるシグナル処理のインターセプト

GNU デバッガー (GDB) により、プログラムの実行中に発生するさまざまな状況で実行を停止できます。プログラムがオペレーティングシステムからシグナルを受け取った時点で実行を停止するには、GDB の キャッチポイント を使用します。

手順

  1. キャッチポイントを設定します。

    (gdb) catch signal signal-type
    Copy to Clipboard Toggle word wrap

    catch signal コマンドは、プログラムがシグナルを受信したときに実行を停止する特別なタイプのブレークポイントを設定します。signal-type オプションは、シグナルのタイプを指定します。すべてのシグナルを取得するには、特別な値 'all' を使用します。

  2. プログラムを実行します。

    • プログラムにより、実行が開始していない場合は開始します。

      (gdb) r
      Copy to Clipboard Toggle word wrap
    • プログラムの実行が停止した場合は、再開します。

      (gdb) c
      Copy to Clipboard Toggle word wrap
  3. GDB は、プログラムが指定のシグナルを受けると実行を停止します。
  4. シグナルを処理しているプログラムコードのデバッグを続けるか、シグナルが受信されたということを把握したうえで実行を再開します。
  5. その後、GDB デバッグセッションを終了するには、以下を実行します。

    (gdb) q
    Copy to Clipboard Toggle word wrap
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat