test

Solaris のシステム管理 (第 2 巻)

第 38 章 ソフトウェアの問題解決の概要

この章では、ソフトウェアの問題の解決についての概要を説明します。システムクラッシュの問題の解決とシステムメッセージの表示などが含まれます。

この章の内容は次のとおりです。

ソフトウェアの問題の解決方法の参照先

ソフトウェアの問題の解決手順については、次の章を参照してください。

システムの問題解決に関する新機能

この節では、Solaris 8 リリースで使用できるようになった、システムの問題解決に関する新機能について説明します。

apptrace

新しいアプリケーションデバッグツール apptrace を使用して、アプリケーション開発者やシステムサポート担当者が、Solaris 共有ライブラリの呼び出しを追跡することによって、アプリケーションやシステムの問題をデバッグできます。この追跡では、障害の発生場所に至るまでの一連のイベントを表示できます。

apptrace ツールの呼び出し追跡機能は、以前の sotruss コマンドよりも信頼性が高くなっています。さらに、apptrace ツールでは、Solaris ライブラリインタフェースに対する関数の引数、戻り値、エラー状況の表示が改善されています。

デフォルトでは、apptrace は、コマンド行に指定した実行可能オブジェクトからそのオブジェクトが依存する各共有ライブラリへの直接呼び出しを追跡します。

詳細は、apptrace(1) のマニュアルページを参照してください。

コアファイル管理の改善

coreadm コマンド

このリリースでは coreadm コマンドが新しく導入されました。coreadm コマンドでは、コアファイルの命名規則が柔軟になり、コアファイルの保存方法が改善されます。たとえば、coreadm コマンドでは、すべてのプロセスコアファイルを同じシステムディレクトリに置くようにシステムを構成できます。そのため、Solaris のプロセスやデーモンが異常終了した場合に、特定のディレクトリにあるコアファイルを調べればよくなり問題の追跡が容易になります。

構成可能な 2 つの新しい core ファイルパス (プロセス別パスとグローバルパス) を、別々に有効にしたり無効にしたりできます。プロセスが異常終了すると、以前の Solaris リリースと同様に core ファイルが現在のディレクトリに作成されます。ただし、グローバルのコアファイルパスが有効で /corefiles/core に設定されている場合、プロセスが異常終了するたびに 2 つのコアファイルが、1 つは現在の作業ディレクトリに、もう 1 つは /corefiles ディレクトリに作成されます。

デフォルトでは Solaris のコアパスとコアファイルの保存方法は従来と同じです。

詳細は、「コアファイルの管理 (coreadm)」と coreadm(1) のマニュアルページを参照してください。

proc ツールによるコアファイルの調査

一部の proc ツールが拡張されてプロセスのコアファイルやライブプロセスが調べられるようになりました。proc ツールは、/proc ファイルシステムの機能を操作するユーティリティです。

現在、コアファイルを処理できるツールは /usr/proc/bin/pstack、pmap、pldd、pflags、pcred です。これらのツールを使用するには、プロセス ID を指定するように、コアファイルの名前をコマンド行に指定します。たとえば、次のように指定します。


$ ./a.out
Segmentation Fault(coredump)
$ /usr/proc/bin/pstack ./core
core './core' of 19305: ./a.out
 000108c4 main     (1, ffbef5cc, ffbef5d4, 20800, 0, 0) + 1c
 00010880 _start   (0, 0, 0, 0, 0, 0) + b8

proc ツールを使ってコアファイルを調べる方法の詳細は、proc(1) のマニュアルページを参照してください。

新しいリモートコンソールメッセージング機能

新しいリモートコンソール機能により、リモートシステムの問題を解決しやすくなりました。

詳細は、「リモートコンソールメッセージングを有効にする」と consadm(1M) のマニュアルページを参照してください。

システムクラッシュの問題の解決

Solaris オペレーティング環境が動作しているシステムがクラッシュした場合は、クラッシュダンプファイルを含む、可能なかぎりの情報を購入先に提供してください。

システムがクラッシュした場合の対処方法

最も重要なことは、次のとおりです。

  1. システムのコンソールメッセージを書き取ります。

    システムがクラッシュした場合は、システムをリブートする前に、まずコンソール画面にメッセージが表示されていないか確認してください。このようなメッセージは、クラッシュした原因を解明するのに役立ちます。システムが自動的にリブートして、コンソールメッセージが画面から消えた場合でも、システムエラーログファイルを表示すれば、これらのメッセージをチェックできます。システムエラーログファイルは、/var/adm/messages (または /usr/adm/messages) に自動的に生成されます。システムエラーログファイルを表示する方法の詳細は、「システムメッセージを表示する方法」を参照してください。

    クラッシュが頻繁に発生して、その原因を特定できない場合は、システムのコンソールや /var/adm/messages ファイルから得られるすべての情報を収集して、購入先に問い合わせください。購入先に問い合わせるときに必要な問題解決のための情報の完全なリストについては、「システムクラッシュの問題の解決」を参照してください。

    システムのクラッシュ後にリブートが失敗する場合は、第 40 章「ソフトウェアで発生するさまざまな問題の解決」を参照してください。

  2. 次のように入力してディスクとの同期をとり、リブートします。


    ok sync

    システムのクラッシュ後にリブートが失敗する場合は、第 40 章「ソフトウェアで発生するさまざまな問題の解決」を参照してください。

  3. savecore コマンドを実行して、スワップ領域に書き込まれたクラッシュ情報を保存します。


    # savecore

クラッシュダンプを自動的に保存する方法については、第 39 章「システムクラッシュ情報の生成と保存」を参照してください。

問題の解決に使用するデータの収集

システムの問題を特定するために、次の質問に答えてください。クラッシュしたシステムの問題を解決するためのデータを収集するには、「システムクラッシュを解決するためのチェックリスト」を参照してください。

表 38-1 システムクラッシュに関するデータの収集

質問 

説明 

問題を再現できるか 

この質問は、再現可能なテストケースは実際のハードウェア問題をデバッグするために重要であることが多いために重要である。購入先では、特殊な計測機構を使用してカーネルを構築して問題を再現し、バグを引き起こし、診断、および修正できる 

Sun 以外のドライバを使用しているか 

ドライバは、カーネルと同じアドレス空間で、カーネルと同じ特権で動作する。したがって、ドライバにバグがあると、システムクラッシュの原因となることがある 

クラッシュの直前にシステムは何を実行していたか 

システムが通常でないこと (新しい負荷テストの実行など) を行なったり、通常よりも高い負荷がシステムにかかったりした場合、クラッシュの原因となることがある 

クラッシュ直前に、異常なコンソールメッセージが表示されたか 

システムは、実際にクラッシュする前に問題の兆候を示すことがある。この情報は役立つことが多い 

/etc/system ファイルに調整パラメタを追加したか

調整パラメタは、システムクラッシュの原因となることがある。たとえば、共有メモリーセグメントを増やした結果、システムが限度以上の多くのメモリーを割り当てようとした 

問題は最近発生するようになったか 

そうであれば、問題の原因は、システムの変更 (たとえば、新しいドライバ、新しいソフトウェア、作業負荷の変化、CPU のアップグレード、メモリーのアップグレードなど) にある可能性がある 

システムクラッシュを解決するためのチェックリスト

クラッシュしたシステムの問題を解決するためのデータを収集するときは、次のチェックリストを使用します。

項目 

ユーザーのデータ 

コアファイルが生成されているか 

 

オペレーティングシステムのリリースと適切なソフトウェアアプリケーションのリリースレベルを確認する 

 

システムのハードウェアを確認する 

sun4d システムの prtdiag 出力を含める

 

パッチはインストールされているか。そうであれば、showrev -p 出力を含める

 

問題を再現できるか 

 

Sun 以外のドライバをシステムで使用しているか 

 

クラッシュ直前のシステムの動作は 

 

クラッシュ直前に、異常なコンソールメッセージが表示されたか 

 

/etc/system ファイルにパラメタを追加したか

 

問題は最近発生するようになったか 

 

システムメッセージの表示

システムのメッセージはコンソールデバイスに表示されます。ほとんどのシステムメッセージは次の形式で表示されます。

[ID msgid facility.priority]

次に例を示します。


[ID 672855 kern.notice] syncing file systems...

カーネルから出されるメッセージには、カーネルモジュール名が次のように表示されます。


Oct 1 14:07:24 mars ufs: [ID 845546 kern.notice] alloc: /: file system full

システムがクラッシュすると、システムのコンソールに次のようなメッセージが表示されることがあります。 


panic: error message

error message は、crash(1M) のマニュアルページに説明されているパニックエラーメッセージの 1 つです。

パニックメッセージより頻度は少ないですが、パニックメッセージではなく次のメッセージが表示されることがあります。 

Watchdog reset !

エラー記録デーモン syslogd は、自動的に様々なシステムの警告やエラーをメッセージファイルに記録します。デフォルトでは、これらのシステムメッセージの多くは、システムコンソールに表示されて、/var/adm ディレクトリに格納されます。システム記録を設定することによって、これらのメッセージを格納する場所を指示できます。詳細は、「システムのメッセージ記録をカスタマイズする方法」を参照してください。これらのメッセージは、失敗の予兆のあるデバイスなど、システム障害をユーザーに警告できます。

/var/adm ディレクトリには、いくつかのメッセージファイルが含まれています。最も新しいメッセージは、/var/adm/messages (および messages.0) にあり、最も古いメッセージは、messages.3 にあります。一定の期間 (通常は 10 日) ごとに、新しい messages ファイルが作成されます。messages.0 のファイル名は messages.1 に、messages.1 は messages.2 に、messages.2 は messages.3 にそれぞれ変更されます。その時点の /var/adm/messages.3 は削除されます。

/var/adm ディレクトリは、メッセージやクラッシュダンプなどのデータを含んでいる大きなファイルを格納するため、多くのディスク容量を消費します。/var/adm ディレクトリが大きくならないようにするために、そして将来のクラッシュダンプが保存できるようにするために、不要なファイルを定期的に削除しなければなりません。crontab を使用すれば、この作業は自動化できます。この作業を自動化する方法については、「クラッシュダンプファイルを削除する方法」と第 30 章「システムイベントのスケジュール設定」を参照してください。

システムメッセージを表示する方法

システムクラッシュまたはリブートによって生成された最近のメッセージを表示するには、dmesg コマンドを使用します。 


$ dmesg

あるいは、more コマンドを使用して、メッセージを 1 画面ごとに表示します。


$ more /var/adm/messages

詳細は、dmesg(1M) のマニュアルページを参照してください。

例 - システムメッセージを表示する

次の例は、dmesg コマンドからの出力を示しています。 


$ dmesg
date starbug genunix: [ID 540533 kern.notice] SunOS Release 5.8 Version 64-bit
date starbug genunix: [ID 223299 kern.notice] Copyright (c) 1983-1999 by Sun Microsystems, Inc.
date starbug genunix: [ID 678236 kern.info] Ethernet address = xx:xx:xx:xx:xx:xx
date starbug unix: [ID 389951 kern.info] mem = 131072K (0x8000000)
date starbug unix: [ID 930857 kern.info] avail mem = 122134528
date starbug rootnex: [ID 466748 kern.info] root nexus = Sun Ultra 5/10 UPA/PCI (UltraSPARC-IIi 333MHz)
date starbug rootnex: [ID 349649 kern.info] pcipsy0 at root: UPA 0x1f 0x0
date starbug genunix: [ID 936769 kern.info] pcipsy0 is /pci@1f,0
date starbug pcipsy: [ID 370704 kern.info] PCI-device: pci@1,1, simba0
date starbug genunix: [ID 936769 kern.info] simba0 is /pci@1f,0/pci@1,1
date starbug pcipsy: [ID 370704 kern.info] PCI-device: pci@1, simba1
date starbug genunix: [ID 936769 kern.info] simba1 is /pci@1f,0/pci@1
date starbug simba: [ID 370704 kern.info] PCI-device: ide@3, uata0
date starbug genunix: [ID 936769 kern.info] uata0 is /pci@1f,0/pci@1,1/ide@3
.
.
.

システムのメッセージ記録のカスタマイズ

/etc/syslog.conf ファイルを変更すると、様々なシステムプロセスが生成するエラーメッセージを記録できます。デフォルトでは、/etc/syslog.conf は、多くのシステムプロセスのメッセージが /var/adm メッセージファイルに格納されるように指示しています。クラッシュとブートのメッセージも、同様にこのファイルに格納されます。/var/adm メッセージを表示する方法については、「システムメッセージを表示する方法」を参照してください。

/etc/syslog.conf ファイルは、タブで区切られた 2 つの列から構成されています。

facility.level ...

action

facility.level

機能またはメッセージや状態のシステムでの出所。コンマで区切られた機能のリスト。機能の値については表 38-2 を参照。level は、記録する状態の重要度や優先順位を示す。優先レベルについては表 38-3 を参照

action

動作フィールドは、メッセージが転送される場所を示す 

次は、デフォルトの /etc/syslog.conf ファイルの例です。 


user.err                                        /dev/sysmsg
user.err                                        /var/adm/messages
user.alert                                      `root, operator'
user.emerg                                      *

この例は、次のユーザーメッセージが自動的に記録されることを意味します。

最も一般的なエラー状態の出所を表 38-2 に示します。最も一般的な優先順位を、重要度順に表 38-3 に示します。

表 38-2 syslog.conf メッセージのソース機能

出所 

説明 

kern

カーネル 

auth

認証 

daemon

すべてのデーモン 

mail

メールシステム 

lp

スプールシステム 

user

ユーザープロセス 

注 -

Solaris 2.6 リリース以降、/etc/syslog.conf ファイルで有効化できる syslog 機能の数の制限は解除されます。以前のリリースでは、機能の数は 20 個に制限されていました。

表 38-3 syslog.conf メッセージの優先レベル

優先順位 

説明 

emerg

システムの緊急事態 

alert

すぐに修正が必要なエラー 

crit

致命的なエラー 

err

その他のエラー 

info

情報メッセージ 

debug

デバッグ用の出力 

none

この設定は出力を記録しない 

システムのメッセージ記録をカスタマイズする方法

  1. スーパーユーザーになります。

  2. 任意のエディタで、/etc/syslog.conf ファイルを編集します。 syslog.conf(4) のマニュアルページで説明している構文に従って、メッセージの出所、優先順位、およびメッセージの記録場所を追加または変更します。

  3. 変更を保存して編集を終了します。

例 - システムのメッセージ記録をカスタマイズする

次の /etc/syslog.conf の user.emerg 機能の例は、ユーザー緊急メッセージを root ユーザーと個別のユーザーに送信します。


user.emerg                                      `root, *'

リモートコンソールメッセージングを有効にする

次の新しいリモートコンソール機能を使うと、リモートシステムの問題を解決しやすくなります。

実行レベルの変更中に補助コンソールメッセージングを使用する

実行レベルの変更中に補助コンソールメッセージングを使う場合は、次の点に注意してください。

対話型ログインセッション中に consadm コマンドを使用する

シリアルポートに接続されている端末からシステムにログインしてから consadm コマンドを使ってこの端末にコンソールメッセージを表示して対話型ログインセッションを行う場合、次の点に注意してください。

補助 (リモート) コンソールを有効にする方法

consadm デーモンは、consadm コマンドで補助コンソールを追加するまでポートの監視を開始しません。セキュリティ機能として、コンソールメッセージは、キャリア信号が失われるまでか、補助コンソールデバイスの選択が解除されるまでの間だけ出力変更されます。そのため、consadm コマンドを使うには、そのポートでキャリア信号が確立されている必要があります。

補助コンソールを有効にする方法の詳細は、consadm(1M) のマニュアルページを参照してください。

  1. スーパーユーザーとしてシステムにログインします。

  2. 補助コンソールを有効にします。


    # consadm -a devicename

  3. 現在の接続が補助コンソールであることを確認します。


    # consadm

例 - 補助 (リモート) コンソールを有効にする


# consadm -a /dev/term/a
# consadm
 /dev/term/a

補助コンソールのリストを表示する方法

  1. スーパーユーザーとしてシステムにログインします。

  2. 次のどちらかの手順に従います。

    1. 補助コンソールのリストを表示します。


      # consadm
/dev/term/a

    2. 持続的補助コンソールのリストを表示します。


      # consadm -p
/dev/term/b

システムリブート後も補助 (リモート) コンソールを有効にする方法

  1. スーパーユーザーとしてシステムにログインします。

  2. 複数のシステムリブート後も補助コンソールを有効にします。


    # consadm -a -p devicename

    このデバイスが持続的な補助コンソールのリストに追加されます。

  3. デバイスが持続的な補助コンソールのリストに追加されているか確認します。


    # consadm

例 - システムリブート後も補助 (リモート) コンソールを有効にする


# consadm -a -p /dev/term/a 
# consadm
/dev/term/a

補助 (リモート) コンソールを無効にする方法

  1. スーパーユーザーとしてシステムにログインします。

  2. 次のどちらかの手順に従います。

    1. 補助コンソールを無効にします。 


      # consadm -d devicename

    2. 補助コンソールを無効にし、持続的な補助コンソールのリストから削除します。 


      # consadm -p -d devicename

  3. 補助コンソールが無効になっていることを確認します。


    # consadm

例 - 補助コンソールが無効になっていることを確認します。


# consadm -d /dev/term/a
# consadm