| ナビゲーションリンクをスキップ | |
| 印刷ビューの終了 | |
|
Oracle Solaris 11.1 での一般的な問題のトラブルシューティング Oracle Solaris 11.1 Information Library (日本語) |
| ナビゲーションリンクをスキップ | |
| 印刷ビューの終了 | |
|
|
Oracle Solaris 11.1 での一般的な問題のトラブルシューティング Oracle Solaris 11.1 Information Library (日本語) |
3. システムおよびソフトウェアのトラブルシューティング (タスク)
システムクラッシュをトラブルシュートするためのチェックリスト
検索パスに関連する問題を解決する (コマンドが見つかりません)
以降のセクションでは、Oracle Solaris のシステムメッセージ機能について説明します。
システムのメッセージはコンソールデバイスに表示されます。ほとんどのシステムメッセージは次の形式で表示されます。
[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
まれに、パニックメッセージではなく次のメッセージが表示されることがあります。
Watchdog reset !
エラー記録デーモン syslogd は、さまざまなシステムの警告やエラーをメッセージファイルに自動的に記録します。デフォルトでは、これらのシステムメッセージの多くは、システムコンソールに表示されて、/var/adm ディレクトリに格納されます。システムメッセージ記録を設定することによって、これらのメッセージを格納する場所を指示できます。詳しくは、「システムのメッセージ記録のカスタマイズ」を参照してください。これらのメッセージは、失敗の予兆のあるデバイスなど、システム障害をユーザーに警告できます。
/var/adm ディレクトリには、いくつかのメッセージファイルが含まれています。もっとも新しいメッセージは、/var/adm/messages (および messages.*) にあり、もっとも古いメッセージは、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 ファイルを使用すれば、このタスクは自動化できます。このタスクの自動化については、『Oracle Solaris 11.1 の管理: デバイスとファイルシステム』の「クラッシュダンプファイルを削除する方法」および『Oracle Solaris 11.1 でのシステム情報、プロセス、およびパフォーマンスの管理』の第 4 章「システムタスクのスケジュール設定 (タスク)」を参照してください。
$ dmesg
あるいは、more コマンドを使用して、メッセージを 1 画面ごとに表示します。
$ more /var/adm/messages
例 3-1 システムメッセージの表示
次の例は、Oracle Solaris 10 システムでの dmesg コマンドからの出力を示します。
$ dmesg Mon Sep 13 14:33:04 MDT 2010 Sep 13 11:06:16 sr1-ubrm-41 svc.startd[7]: [ID 122153 daemon.warning] ... Sep 13 11:12:55 sr1-ubrm-41 last message repeated 398 times Sep 13 11:12:56 sr1-ubrm-41 svc.startd[7]: [ID 122153 daemon.warning] ... Sep 13 11:15:16 sr1-ubrm-41 last message repeated 139 times Sep 13 11:15:16 sr1-ubrm-41 xscreensaver[25520]: ,,, Sep 13 11:15:16 sr1-ubrm-41 xscreensaver[25520]: ... Sep 13 11:15:17 sr1-ubrm-41 svc.startd[7]: [ID 122153 daemon.warning]... . . .
参照
詳細は、dmesg(1M) のマニュアルページを参照してください。
システムログファイルは、root の crontab ファイルのエントリから logadm コマンドによって実行されます。/usr/lib/newsyslog スクリプトは使用されません。
このシステムログローテーションは、/etc/logadm.conf ファイルに定義されます。このファイルには、syslogd などのプロセスのログローテーションエントリが含まれています。たとえば、/etc/logadm.conf ファイルにある 1 つのエントリは、/var/log/syslog ファイルが空でなければローテーションが毎週実行されることを示しています。つまり、最新の syslog ファイルが syslog.0 になり、その次に新しい syslog ファイルが syslog.1 になります。最新からさかのぼって 8 つまでの syslog ログファイルが保存されます。
また、/etc/logadm.conf ファイルには、最後のログローテーション実行時のタイムスタンプも含まれます。
logadm コマンドを使用して、必要に応じてシステムログをカスタマイズしたり、/etc/logadm.conf ファイルにログを追加したりすることができます。
たとえば、Apache アクセスとエラーログのローテーションを実行するには、次のコマンドを使用します。
# logadm -w /var/apache/logs/access_log -s 100m # logadm -w /var/apache/logs/error_log -s 10m
この例では、Apache の access_log ファイルのローテーションは、そのサイズが 100M バイトに達したときに実行され、そのファイル名に .0、 .1 などのように接尾辞が付けられます。また、古い access_log ファイルのコピーが 10 個保存されます。また、error_log のローテーションは、そのサイズが 10M バイトに達したときに実行され、access_log ファイルと同様に、接尾辞が付けられ、コピーが保存されます。
前述の Apache ログローテーションの例における /etc/logadm.conf エントリの例は、次のようになります。
# cat /etc/logadm.conf . . . /var/apache/logs/error_log -s 10m /var/apache/logs/access_log -s 100m
詳細は、logadm(1M) のマニュアルページを参照してください。
スーパーユーザーでログインするか、同等の役割 (ログ管理の権限を持つ) でアクセスすることによって、logadm コマンドを使用できます。RBAC を使用すると、logadm コマンドへのアクセス権を与えることによって、root 以外のユーザーにログファイルを管理する権限を与えることができます。
たとえば、次のエントリを /etc/user_attr ファイルに追加すれば、logadm コマンドを使用する権限がユーザー andy に与えられます。
andy::::profiles=Log Management
/etc/syslog.conf ファイルを変更すると、さまざまなシステムプロセスが生成するさらに多くのエラーメッセージを記録できます。デフォルトでは、/etc/syslog.conf は、多くのシステムプロセスのメッセージが /var/adm/messages ファイルに格納されるように指示します。クラッシュとブートのメッセージも、同様にこのファイルに格納されます。/var/adm メッセージを表示する方法については、「システムメッセージを表示する方法」を参照してください。
/etc/syslog.conf ファイルは、タブで区切られた 2 つの列から構成されています。
facility.level ... action
機能またはメッセージや状態のシステムでの出所。コンマで区切られた機能のリスト。機能の値については、表 3-2 を参照してください。level は、記録する状態の重要度や優先順位を示します。優先レベルについては、表 3-3 を参照してください。
同じ機能の 2 つのエントリは、それぞれの優先順位が異なる場合、同じ行に入力しないでください。syslog ファイルに優先順位を入力すると、この優先順位以上のすべてのメッセージが記録され、最後のメッセージが優先されます。指定の機能とレベルに対し、syslogd はそのレベル以上のすべてのメッセージを記録します。
動作フィールドは、メッセージが転送される場所を示します。
次の例は、デフォルトの /etc/syslog.conf ファイルのサンプルを示します。
user.err /dev/sysmsg user.err /var/adm/messages user.alert `root, operator' user.emerg *
この例は、次のユーザーメッセージが自動的に記録されることを意味します。
ユーザーエラーはコンソールに出力され、/var/adm/messages ファイルにも記録されます。
早急な対応が必要なユーザーメッセージ (alert) は、root ユーザーと operator ユーザーに送信されます。
ユーザー緊急メッセージは、各ユーザーに送信されます。
注 - エントリを個別の行に入力すると、/etc/syslog.conf ファイルでログの対象が複数回指定された場合に、メッセージのログ順が変わることがあります。単独行のエントリに複数のセレクタを指定できます。その際、セレクタはセミコロンで区切ります。
一般的なエラー状態の送信元を次の表に示します。一般的な優先順位を、重要度順に表 3-3 に示します。
表 3-2 syslog.conf メッセージの送信元の機能
|
表 3-3 syslog.conf メッセージの優先レベル
|
『Oracle Solaris 11.1 の管理: セキュリティーサービス』の「割り当てられている管理権限を使用する方法」を参照してください。
$ pfedit /etc/syslog.conf
例 3-2 システムのメッセージ記録のカスタマイズ
次の /etc/syslog.conf の user.emerg 機能の例は、ユーザー緊急メッセージを root ユーザーおよび個別のユーザーに送信します。
user.emerg `root, *'
次の新しいリモートコンソール機能を使うと、リモートシステムの問題をトラブルシュートしやすくなります。
consadm コマンドでは、補助 (またはリモート) コンソールとしてシリアルデバイスを選択できます。consadm コマンドを使用すると、システム管理者は 1 つまたは複数のシリアルポートを構成して、出力先が変更されたコンソールメッセージを表示したり、システムの実行レベルが変わったときに sulogin セッションをサポートしたりできます。この機能を使用して、モデム付きのシリアルポートにダイヤルインしてコンソールメッセージを監視し、init 状態の変更を表示できます(詳細については、sulogin(1M) と、以下の詳しい手順を参照)。
補助コンソールとして構成されたポートからシステムにログインすることもできますが、このポートは主に、デフォルトコンソールに表示される情報を表示する出力デバイスです。ブートスクリプトやその他のアプリケーションがデフォルトコンソールに対して読み書きを行う場合、書き込み出力はすべての補助コンソールに出力されますが、入力はデフォルトコンソールからだけ読み込まれます対話型ログインセッションでの consadm コマンドの使用方法については、「対話型ログインセッションで consadm コマンドを使用するためのガイドライン」を参照してください。
コンソール出力は、新しい仮想デバイス /dev/sysmsg に書き込まれる、カーネルメッセージと syslog メッセージからなります。さらに、rc スクリプト起動メッセージが /dev/msglog に書き込まれます。以前のリリースでは、これらのメッセージはすべて /dev/console に書き込まれていました。
スクリプトメッセージを補助コンソールに表示したい場合は、コンソール出力を /dev/console に出力しているスクリプトで出力先を /dev/msglog に変更する必要があります。メッセージ出力先を補助デバイスに変更したい場合は、/dev/console を参照しているプログラムで syslog() または strlog() を使用するように明示的に変更してください。
consadm コマンドは、デーモンを実行して補助コンソールデバイスを監視します。補助コンソールに指定された表示デバイスがハングアップしたりキャリア信号がなくなって切り離されると、そのデバイスは補助コンソールデバイスのリストから削除され、アクティブでなくなります。1 つまたは複数の補助コンソールを有効にしても、メッセージがデフォルトコンソールに表示されなくなるわけではありません。メッセージは引き続き /dev/console に表示されます。
実行レベルの変更中に補助コンソールメッセージングを使う場合は、次の点に注意してください。
システムのブート時に実行する rc スクリプトにユーザーの入力がある場合は、補助コンソールから入力を行うことはできません。入力はデフォルトコンソールから行う必要があります。
実行レベルの変更中に、スーパーユーザーパスワード入力を要求するために sulogin プログラムが init によって呼び出されます。このプログラムは、デフォルトのコンソールデバイスだけでなく各補助デバイスにもスーパーユーザーパスワードの入力要求を送信するように変更されています。
システムがシングルユーザーモードで動作し、1 つまたは複数の補助コンソールが consadm コマンドによって有効になっていると、最初のデバイスでコンソールログインセッションが実行され、正確なスーパーユーザーパスワードを要求する sulogin プロンプトが表示されます。コンソールデバイスから正しいパスワードを受け取ると、sulogin は他のすべてのコンソールデバイスからの入力を受信できないようにします。
コンソールの 1 つがシングルユーザー特権を取得すると、デフォルトコンソールとその他の補助コンソールにメッセージが出力されます。このメッセージは、どのデバイスから正しいスーパーユーザーパスワードが入力され、コンソールになったかを示します。シングルユーザーシェルが動作する補助コンソールのキャリア信号が失われると、次のどちらかのアクションが起ることがあります。
補助コンソールが実行レベル 1 のシステムを表している場合は、システムはデフォルトの実行レベルに移行します。
補助コンソールが実行レベル S のシステムを表している場合は、シェルから init s または shutdown コマンドが入力されたデバイスに「ENTER RUN LEVEL (0-6, s or S): 」というメッセージが表示されます。このデバイスのキャリア信号も失われている場合は、キャリア信号を復活して正確な実行レベルを入力する必要があります。init コマンドや shutdown コマンドを実行しても、実行レベルプロンプトが再表示されることはありません。
シリアルポートを使用してシステムにログインしている場合には、init または shutdownコマンドを使用して別の実行レベルに移行すると、このデバイスが補助コンソールかどうかに関係なくログインセッションは失われます。この状況は、補助コンソール機能がない リリースと同じです。
consadm コマンドを使って補助コンソールにするデバイスを選択すると、システムをリブートするか補助コンソールの選択を解除するまで、そのデバイスは補助コンソールとして有効です。ただし、consadm コマンドには、システムリブート後も同じデバイスを補助コンソールとして使用するオプションがあります(以下の詳しい手順を参照)。
シリアルポートに接続された端末からシステムにログインしてから、 consadm コマンドを使ってこの端末にコンソールメッセージを表示して、対話型ログインセッションを行う場合、次の点に注意してください。
この端末で対話型ログインセッションを行う場合、補助コンソールがアクティブだと、コンソールメッセージは /dev/sysmsg デバイスまたは /dev/msglog デバイスに送られます。
この端末からコマンドを発行すると、入力はデフォルトコンソール (/dev/console) ではなく対話型セッションに送られます。
init コマンドを実行して実行レベルを変更すると、リモートコンソールソフトウェアは対話型セッションを終了し、sulogin プログラムを実行します。この時点では、入力はこの端末からだけ可能で、入力はコンソールデバイスから行われたかのように扱われます。そのため、「実行レベルの変更中に補助コンソールメッセージングを使用する」 の説明のとおりに、sulogin プログラムにパスワードを入力できます。
次に、(補助) 端末から正しいパスワードを入力すると、補助コンソールは、対話型 sulogin セッションを実行し、デフォルトコンソールおよび競合する補助コンソールを使えなくします。つまり、その端末は実質的にシステムコンソールとして機能します。
この端末から実行レベル 3 または別の実行レベルに変更できます。実行レベルを変更すると、すべてのコンソールデバイスで sulogin が再び実行されます。終了したり、システムが実行レベル 3 で起動されるように指定すると、どの補助コンソールからも入力を行えなくなります。すべての補助コンソールはコンソールメッセージを表示するだけのデバイスに戻ります。
システムが起動する際には、デフォルトのコンソールデバイスから rc スクリプトに情報を入力する必要があります。システムが再び起動すると login プログラムがシリアルポートで実行されるため、別の対話型セッションを開始できます。そのデバイスを補助コンソールに指定していれば、コンソールメッセージはその端末に引き続き出力されます。ただし、端末からの入力はすべて対話型セッションに送られます。
consadm デーモンは、consadm コマンドで補助コンソールを追加するまでポートの監視を開始しません。セキュリティー機能として、コンソールメッセージは、キャリア信号が失われるまでか、補助コンソールデバイスの選択が解除されるまでの間だけ出力変更されます。そのため、consadm コマンドを使うには、そのポートでキャリア信号が確立されている必要があります。
補助コンソールの有効化については、consadm(1m) のマニュアルページを参照してください。
『Oracle Solaris 11.1 の管理: セキュリティーサービス』の「割り当てられている管理権限を使用する方法」を参照してください。
# consadm -a devicename
# consadm
例 3-3 補助 (リモート) コンソールを有効にする
# consadm -a /dev/term/a # consadm /dev/term/a
『Oracle Solaris 11.1 の管理: セキュリティーサービス』の「割り当てられている管理権限を使用する方法」を参照してください。
『Oracle Solaris 11.1 の管理: セキュリティーサービス』の「割り当てられている管理権限を使用する方法」を参照してください。
# consadm -a -p devicename
このデバイスが持続的な補助コンソールのリストに追加されます。
# consadm
例 3-4 システムリブート後も補助 (リモート) コンソールを有効にする
# consadm -a -p /dev/term/a # consadm /dev/term/a
『Oracle Solaris 11.1 の管理: セキュリティーサービス』の「割り当てられている管理権限を使用する方法」を参照してください。
# consadm
例 3-5 補助 (リモート) コンソールを無効にする
# consadm -d /dev/term/a # consadm
|
