サード パーティ製ツールを使用したトラブルシューティングのシナリオ

シナリオ 1：コア ファイルが生成されない

Windows 環境で特に役立つツールの 1 つは、Process Monitor (ProcMon) アプリケーションです。Process Monitor は、Windows SysInternals ツール スイートの一部で、Microsoft の Web サイトからダウンロードできます。

ProcMon は、パスとレジストリへのアクセス、およびシステム全体で実行された検索を表示できます。すべてのアクセスおよび検索を表示したり、その結果をフィルター処理して特定の情報を表示したりできます。次の例は、コア ファイルの生成における問題、および ProcMon を使用して問題をトラブルシューティングする方法を示しています。

問題

cobconfig.cfg ファイルで、アプリケーションがクラッシュした場合に MFCore.pid@time_date という名前のコア ファイルを c:\logs ディレクトリに生成するように、core_on_error および core_filename ランタイム チューナーを設定しました。しかし、アプリケーションがクラッシュしても、コア ファイルが生成されていないようです。

ProcMon によるトラブルシューティング

ProcMan アプリケーションは、対象とするアプリケーションと同時に実行され、設定されたフィルターに基づいてそのアクティビティを追跡します。次の手順を使用して、コア ファイルの生成に関する問題をトラブルシューティングできます。

1. ProcMon を起動し、フィルターを設定して、文字列 MFCore を含むパスへの参照をすべてトレースします。
   
   
2. クラッシュするようにアプリケーションを再実行します。
3. ProcMon で出力を表示します。
   
   

   この例では、ProcMon の出力から、設定したランタイム チューナーによって logsMFCore... という名前のファイルが C: ドライブのルート ディレクトリに作成された (MFCore... という名前のファイルが C:\logs ディレクトリにではなく) ことがわかります。これは、core_filename ランタイム チューナーの定義方法に誤りがあることを示しています。

4. cobconfig.cfg ファイルを編集します。現在は次のようになっています。

   set core_on_error=131
   set core_filename="C:\\logs\MFCore.%p@%t_%d"

   core_filename に設定されている値を調べると、logs ディレクトリの指定とファイル名の指定の間にバックスラッシュ (\) が 1 つしかないことがわかります。

   cobconfig.cfg ファイル内のバックスラッシュ文字はエスケープされるため、この単一のバックスラッシュが削除されて、間違った場所にファイルが配置されていました。

5. 次のように、core_filename の値でのディレクトリ指定の後に 2 つ目のバックスラッシュを追加します。

   set core_filename="C:\\logs\\MFCore.%p@%t_%d"

6. 保存してエディターを閉じます。
7. アプリケーションを再実行します。今度は、アプリケーションがクラッシュすると、コア ファイルが正しい場所に表示されます。

シナリオ 2：Windows マシンから UNIX Fileshare サーバーに接続できない

問題

Windows マシンを Fileshare クライアントとして設定し、Redhat Linux を実行しているリモートの Fileshare サーバーへのポート 8765 を使用したリモート接続を定義したところ、Fileshare サーバーへの接続が機能しません。

ncat によるトラブルシューティング

このようなシナリオで最初に確認すべき点は、Windows マシンへのネットワーク接続です。そのために、ncat (NCAT.ORG から入手可能) を使用して、ごく基本的なクライアント/サーバー接続をセットアップできます。ncat の接続が機能する場合は、ネットワークの問題が原因である可能性を除外できます。このシナリオでは、次の ncat コマンドを実行できます。

• UNIX マシンで、ネットワーク接続を確立する場合：

  ncat -l localhost 2000

• Windows マシンで、UNIX マシンへのネットワーク接続を確立する場合：

  ncat host-name 2000

  host-name は、UNIX Fileshare サーバーの名前です。

このシナリオでは、両方の接続が正常に確立されました。次のステップは、接続自体で何が起きているかを調査することです。

Wireshark および tcpdup によるトラブルシューティング

tcpdump と Wireshark を組み合わせて使用して、ネットワークを通過するトラフィックを分析できます。どちらも、ネットワークに関するさまざまな問題を分析するのに役立つ強力なツールです。

Windows (クライアント) マシンで Wireshark を実行すると、送信に対する応答が受信されていないことがわかります。これは、Redhat (サーバー) 側に何らかの問題があることを示唆しています。これをトラブルシューティングするには、次の手順を実行します。

1. Windows (クライアント) マシンで Wireshark を起動します。
2. サーバー マシンの IP アドレスへの接続を表示するようにフィルターを設定します。
3. Fileshare サーバーが実行されているポート 8765 に tcp 要求を送信します。
4. 出力を表示します。
   
   

   この出力から、ポート 8765 に要求を送信したものの、応答を受信していないことがわかります。

Redhat (サーバー) 側で何が起きているかを調べるには、tcpdump を使用できます。これは、Wireshark に似た機能を持つ、Unix/Linux システム用のツールです。

• コマンド プロンプトで、次のように tcpdump を実行して、Fileshare のポート 8765 上のトラフィックのみを返すフィルターを設定します。

  tcpdump -i eth1 'port 8765'

  tcpdump の出力を見ると、この結果が空であり、ネットワーク要求が Redhat マシンに到達していないと考えられます。

解決方法

環境をさらに調査したところ、ファイアウォールが 3000 を超えるポート番号での要求をブロックしていることがわかりました。つまり、ncat の接続は、ポート 2000 で実行されたため成功しましたが、Wireshark/tcpdump の接続は、ポート 8765 がファイアウォールでブロックされていたため成功しませんでした。