この章では、ソフトウェアの問題の解決についての概要を説明します。システムクラッシュの問題の解決とシステムメッセージの表示などが含まれます。
この章の内容は次のとおりです。
この節では、Solaris 9 リリースでの新機能について説明します。
Solaris 9 リリースでは、システムログファイルローテーションが、ルートの 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 ファイルのローテーションは、そのサイズが 100 MB に達したときに実行され、そのファイル名に .0、 .1 などのように接尾辞が付けられます。また、古い access_log ファイルのコピーが 10 個保存されます。また、error_log のローテーションは、そのサイズが 10 MB に達したときに実行され、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 コマンドへのアクセス権を与えることで、ルート以外のユーザーにログ管理の権限を与えることができます。
たとえば、次のエントリを /etc/user_attr ファイルに追加して、logadm コマンドを使用できる andy をユーザーに与えます
andy::::profiles=Log Management |
または、Solaris 管理コンソールを使用して、ログ管理の役割を設定できます。役割の設定に関する詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「役割によるアクセス制御 (概要)」を参照してください。
Solaris の前のリリースでは、root のシェルを存在しないシェルに変更すると、CD またはネットワークからシステムをブートし、/etc/passwd ファイルにある root シェルを修正する必要がありました。
Solaris 9 リリースでは、root に存在しないシェルを間違って入力しても、次のいずれかを実行すると、root のシェルが自動的に /sbin/sh にフォールバックされます。
su コマンドを使用して、スーパーユーザー (root) のアカウントになる。
シングルユーザーモードのプロンプトで root のパスワードを入力する。
詳細については、su(1M) のマニュアルページを参照してください。
問題解決の手順 |
参照箇所 |
---|---|
システムクラッシュ情報の管理 | |
コアファイルの管理 | |
リブート失敗、バックアップ問題などのソフトウェアの問題解決 | |
ファイルアクセスの問題解決 | |
印刷の問題解決 | |
UFS ファイルシステムの不整合の解決 | |
ソフトウェアパッケージの問題解決 |
Solaris オペレーティング環境が動作しているシステムがクラッシュした場合は、クラッシュダンプファイルを含む、可能なかぎりの情報を購入先に提供してください。
最も重要なことは、次のとおりです。
システムのコンソールメッセージを書き取ります。
システムがクラッシュした場合は、システムをリブートする前に、まずコンソール画面にメッセージが表示されていないか確認してください。このようなメッセージは、クラッシュした原因を解明するのに役立ちます。システムが自動的にリブートして、コンソールメッセージが画面から消えた場合でも、システムエラーログファイル /var/adm/messages を表示すれば、これらのメッセージをチェックできます。システムエラーログファイルを表示する方法の詳細は、システムメッセージを表示する方法を参照してください。
クラッシュが頻繁に発生して、その原因を特定できない場合は、システムのコンソールや /var/adm/messages ファイルから得られるすべての情報を収集して、購入先に問い合わせください。購入先に問い合わせるときに必要な問題解決のための情報の完全なリストについては、システムクラッシュの問題の解決を参照してください。
システムのクラッシュ後にリブートが失敗する場合は、第 29 章「ソフトウェアで発生するさまざまな問題の解決 (手順)」を参照してください。
次のように入力してディスクとの同期をとり、リブートします。
ok sync |
システムのクラッシュ後にリブートが失敗する場合は、第 29 章「ソフトウェアで発生するさまざまな問題の解決 (手順)」を参照してください。
また、システムクラッシュダンプがシステムのクラッシュ後に生成されたかどうかを確認してください。デフォルトでは、システムクラッシュダンプが保存されます。クラッシュダンプの詳細については、第 28 章「システムクラッシュ情報の管理 (手順)」を参照してください。
システムの問題を特定するために、次の質問に答えてください。クラッシュしたシステムの問題を解決するためのデータを収集するには、システムクラッシュを解決するためのチェックリストを参照してください。
表 26–1 システムクラッシュに関するデータの収集
質問 |
説明 |
---|---|
問題を再現できるか |
この質問は、再現可能なテストケースは実際のハードウェア問題をデバッグするために重要であることが多いために重要である。購入先では、特殊な計測機構を使用してカーネルを構築して問題を再現し、バグを引き起こし、診断、および修正できる |
Sun 以外のドライバを使用しているか |
ドライバは、カーネルと同じアドレス空間で、カーネルと同じ特権で動作する。したがって、ドライバにバグがあると、システムクラッシュの原因となることがある |
クラッシュの直前にシステムは何を実行していたか |
システムが通常でないこと (新しい負荷テストの実行など) を行なったり、通常よりも高い負荷がシステムにかかったりした場合、クラッシュの原因となることがある |
クラッシュ直前に、異常なコンソールメッセージが表示されたか |
システムは、実際にクラッシュする前に問題の兆候を示すことがある。この情報は役立つことが多い |
/etc/system ファイルに調整パラメータを追加したか |
調整パラメータは、システムクラッシュの原因となることがある。たとえば、共有メモリーセグメントを増やした結果、システムが限度以上の多くのメモリーを割り当てようとした |
問題は最近発生するようになったか |
そうであれば、問題の原因は、システムの変更 (たとえば、新しいドライバ、新しいソフトウェア、作業負荷の変化、CPU のアップグレード、メモリーのアップグレードなど) にある可能性がある |
クラッシュしたシステムの問題を解決するためのデータを収集するときは、次のチェックリストを使用します。
項目 |
ユーザーのデータ |
---|---|
システムクラッシュダンプがあるか |
|
オペレーティングシステムのリリースと適切なソフトウェアアプリケーションのリリースレベルを確認する |
|
システムのハードウェアを確認する sun4u システムの prtdiag 出力を含める他のシステムの Explorer 出力を含める |
|
パッチはインストールされているか。そうであれば、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 |
パニックメッセージより頻度は少ないですが、パニックメッセージではなく次のメッセージが表示されることがあります。
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 ファイルを使用すれば、この作業は自動化できます。この作業の自動化の詳細については、クラッシュダンプファイルを削除する方法と第 18 章「システムタスクのスケジュール設定 (手順)」を参照してください。
システムクラッシュまたはリブートによって生成された最近のメッセージを表示するには、dmesg コマンドを使用します。
$ dmesg |
あるいは、more コマンドを使用して、メッセージを 1 画面ごとに表示します。
$ more /var/adm/messages |
詳細については、dmesg(1M) のマニュアルページを参照してください。
$ dmesg Jan 3 08:44:41 starbug genunix: [ID 540533 kern.notice] SunOS Release 5.9 ... Jan 3 08:44:41 starbug genunix: [ID 913631 kern.notice] Copyright 1983-2002 ... Jan 3 08:44:41 starbug genunix: [ID 678236 kern.info] Ethernet address ... Jan 3 08:44:41 starbug unix: [ID 389951 kern.info] mem = 131072K (0x8000000) Jan 3 08:44:41 starbug unix: [ID 930857 kern.info] avail mem = 121888768 Jan 3 08:44:41 starbug rootnex: [ID 466748 kern.info] root nexus = Sun Ultra 5/ 10 UPA/PCI (UltraSPARC-IIi 333MHz) Jan 3 08:44:41 starbug rootnex: [ID 349649 kern.info] pcipsy0 at root: UPA 0x1f0x0 Jan 3 08:44:41 starbug genunix: [ID 936769 kern.info] pcipsy0 is /pci@1f,0 Jan 3 08:44:41 starbug pcipsy: [ID 370704 kern.info] PCI-device: pci@1,1, simba0 Jan 3 08:44:41 starbug genunix: [ID 936769 kern.info] simba0 is /pci@1f,0/pci@1,1 Jan 3 08:44:41 starbug pcipsy: [ID 370704 kern.info] PCI-device: pci@1, simba1 Jan 3 08:44:41 starbug genunix: [ID 936769 kern.info] simba1 is /pci@1f,0/pci@1 Jan 3 08:44:57 starbug simba: [ID 370704 kern.info] PCI-device: ide@3, uata0 Jan 3 08:44:57 starbug genunix: [ID 936769 kern.info] uata0 is /pci@1f,0/pci@1, 1/ide@3 Jan 3 08:44:57 starbug uata: [ID 114370 kern.info] dad0 at pci1095,6460 . . . |
/etc/syslog.conf ファイルを変更すると、様々なシステムプロセスが生成するエラーメッセージを記録できます。デフォルトでは、/etc/syslog.conf は、多くのシステムプロセスのメッセージが /var/adm/messages ファイルに格納されるように指示します。クラッシュとブートのメッセージも、同様にこのファイルに格納されます。/var/adm メッセージを表示する方法については、システムメッセージを表示する方法を参照してください。
/etc/syslog.conf ファイルは、タブで区切られた 2 つの列から構成されています。
facility.level ... action |
facility.level |
機能またはメッセージや状態のシステムでの出所。コンマで区切られた機能のリスト。機能の値については表 26–2 を参照。level は、記録する状態の重要度や優先順位を示す。優先レベルについては表 26–3 を参照 |
action |
動作フィールドは、メッセージが転送される場所を示す |
次は、デフォルトの /etc/syslog.conf ファイルの例です。
user.err /dev/sysmsg user.err /var/adm/messages user.alert `root, operator' user.emerg * |
この例は、次のユーザーメッセージが自動的に記録されることを意味します。
ユーザーエラーはコンソールに出力され、/var/adm/messages ファイルにも記録されます。
早急な対応が必要なユーザーメッセージ (alert) は、root ユーザーと operator ユーザーに送信されます。
ユーザー緊急メッセージは、各ユーザーに送信されます。
最も一般的なエラー状態の送信元を表 26–2 に示します。最も一般的な優先順位を、重要度順に表 26–3 に示します。
表 26–2 syslog.conf メッセージの機能
送信元 |
説明 |
---|---|
カーネル |
|
認証 |
|
daemon |
すべてのデーモン |
|
メールシステム |
lp |
スプールシステム |
user |
ユーザープロセス |
/etc/syslog.conf ファイルで有効化できる syslog 機能の数に制限はありません。
優先順位 |
説明 |
---|---|
emerg |
システムの緊急事態 |
alert |
すぐに修正が必要なエラー |
crit |
致命的なエラー |
err |
その他のエラー |
info |
情報メッセージ |
debug |
デバッグ用の出力 |
none |
この設定は出力を記録しない |
スーパーユーザーになります。
/etc/syslog.conf ファイルを編集します。syslog.conf(4) のマニュアルページで説明している構文に従って、メッセージの送信元、優先順位、およびメッセージの格納場所を追加または変更します。
変更を保存して編集を終了します。
次の /etc/syslog.conf の user.emerg 機能の例は、ユーザー緊急メッセージを root ユーザーと個別のユーザーに送信します。
user.emerg `root, *' |
次の新しいリモートコンソール機能を使うと、リモートシステムの問題を解決しやすくなります。
consadm コマンドでは、補助 (またはリモート) コンソールとしてシリアルデバイスを選択できます。consadm コマンドを使用して、システム管理者は 1 つまたは複数のシリアルポートを構成して、出力先が変更されたコンソールメッセージを表示したり、システムの実行レベルが変わったときに sulogin セッションをサポートしたりできます。この機能を使用して、モデム付きのシリアルポートにダイヤルインしてコンソールメッセージを監視し、init 状態の変更を表示できます (詳細については、sulogin(1M) のマニュアルページと以下の詳しい手順を参照) 。
補助コンソールとして構成されたポートからシステムにログインすることもできますが、このポートは主に、デフォルトコンソールに表示される情報を表示する出力デバイスです。ブートスクリプトやその他のアプリケーションがデフォルトコンソールに対して読み書きを行う場合、書き込み出力はすべての補助コンソールに出力されますが、入力はデフォルトコンソールからだけ読み込まれます (対話型ログインセッションでの consadm コマンドの使用方法については、対話型ログインセッション中に consadm コマンドを使用するを参照)。
コンソール出力はカーネルメッセージと syslog メッセージからなり、新しい仮想デバイス /dev/sysmsg に書き込まれます。さらに、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コマンドを使用して別の実行レベルに移行すると、このデバイスが補助コンソールかどうかに関係なくログインセッションは失われます。この状況は、補助コンソール機能がない Solaris リリースと同じです。
consadm コマンドを使って補助コンソールにするデバイスを選択すると、システムをリブートするか補助コンソールの選択を解除するまで、そのデバイスは補助コンソールとして有効です。ただし、consadm コマンドには、複数のシステムリブートにまたがってデバイスを補助コンソールとして使用するオプションがあります (以下の詳しい手順を参照)。
シリアルポートに接続されている端末からシステムにログインしてから consadm コマンドを使ってこの端末にコンソールメッセージを表示して対話型ログインセッションを行う場合、次の点に注意してください。
この端末で対話型ログインセッションを行う場合、補助コンソールがアクティブだと、コンソールメッセージは /dev/sysmsg デバイスまたは /dev/msglog デバイスに送られます。
この端末からコマンドを発行すると、入力はデフォルトコンソール (/dev/console) ではなく対話型セッションに送られます。
init コマンドを実行して実行レベルを変更すると、リモートコンソールソフトウェアは対話型セッションを終了し、sulogin プログラムを実行します。この時点では、入力はこの端末からだけ可能で、入力はコンソールデバイスから行われたかのように扱われます。そのため、実行レベルの変更中に補助コンソールメッセージングを使用するの説明のとおりに、sulogin プログラムにパスワードを入力できます。
次に、(補助) 端末から正しいパスワードを入力すると、補助コンソールは、対話型 sulogin セッションを実行し、デフォルトコンソールおよび競合する補助コンソールを使えなくします。つまり、その端末は実質的にシステムコンソールとして機能します。
この端末から実行レベル 3 または別の実行レベルに変更できます。実行レベルを変更すると、すべてのコンソールデバイスで sulogin が再び実行されます。終了したり、システムが実行レベル 3 で起動されるように指定すると、どの補助コンソールからも入力を行えなくなります。すべての補助コンソールはコンソールメッセージを表示するだけのデバイスに戻ります。
システムが起動する際には、デフォルトのコンソールデバイスから rc スクリプトに情報を入力する必要があります。システムが再び起動すると login プログラムがシリアルポートで実行されるため、別の対話型セッションを開始できます。そのデバイスを補助コンソールに指定していれば、コンソールメッセージはその端末に引き続き出力されます。ただし、端末からの入力はすべて対話型セッションに送られます。
consadm デーモンは、consadm コマンドで補助コンソールを追加するまでポートの監視を開始しません。セキュリティ機能として、コンソールメッセージは、キャリア信号が失われるまでか、補助コンソールデバイスの選択が解除されるまでの間だけ出力変更されます。そのため、consadm コマンドを使うには、そのポートでキャリア信号が確立されている必要があります。
補助コンソールを有効にする方法の詳細については、consadm(1M) のマニュアルページを参照してください。
システムにスーパーユーザーとしてログインします。
補助コンソールを有効にします。
# consadm -a devicename |
現在の接続が補助コンソールであることを確認します。
# consadm |
# consadm -a /dev/term/a # consadm /dev/term/a |
システムにスーパーユーザーとしてログインします。
複数のシステムリブート後も補助コンソールを有効にします。
# consadm -a -p devicename |
このデバイスが持続的な補助コンソールのリストに追加されます。
デバイスが持続的な補助コンソールのリストに追加されているか確認します。
# consadm |
# consadm -a -p /dev/term/a # consadm /dev/term/a |
# consadm -d /dev/term/a # consadm |