SMF ベストプラクティスおよびトラブルシューティング
この付録では、次のことに関するベストプラクティスおよびトラブルシューティングについて説明します。
-
機能低下、オフライン、または保守状態になっているサービスインスタンスの修復
-
SMF リポジトリの問題の診断と修復
-
SMF 起動メッセージングの量の指定
-
ブートする SMF マイルストーンの指定
-
システムブート問題の調査
-
SMF サービスへの inetd サービスの変換
SMF ベストプラクティス
ほとんどのサービスは構成ポリシーを記述します。必要な構成が実装されていない場合は、サービスを変更してポリシーの説明を変更してください。サービスプロパティーの値を変更するか、別のプロパティー値で新しいサービスインスタンスを作成します。サービスインスタンスを無効にして、SMF サービスで管理する予定の構成ファイルを編集しないでください。Oracle Solaris の増加している基本機能は SMF サービスプロパティーで構成され、構成ファイルを編集して構成するわけではありません。
Oracle またはサードパーティーソフトウェアベンダーから提供されるマニフェストおよびシステムプロファイルは、変更しないでください。これらのマニフェストおよびプロファイルは、システムをアップグレードするときに置き換えられ、これらのファイルに加えた変更は失われます。代わりに、次のいずれかを行います。
-
サービスインスタンスの追加の説明に従って、別のプロパティー値を持つ新しいサービスインスタンスを追加します。
-
サービスをカスタマイズするためのプロファイルを作成します。svcbundle コマンドまたは svccfg extract コマンドを使用して、プロファイルファイルを作成します。そのファイルのプロパティー値をカスタマイズして、それぞれのカスタマイズの理由に関するコメントを含めます。プロファイルファイルを /etc/svc/profile/site にコピーし、manifest-import サービスを再起動します。
複数のシステムに同じカスタム構成を適用するには、各システムの /etc/svc/profile/site に同じプロファイルファイルをコピーし、それぞれのシステムで manifest-import サービスを再起動します。各システムへのプロファイルの配信を自動化するには、プロファイルをパッケージ化します。複数のシステムの構成を参照してください。
svccfg コマンドまたは inetadm コマンドを使用して、プロパティーを直接操作します。svccfg コマンドを使用してプロパティー値を変更する場合は、必ず、構成変更についての説明に従ってサービスインスタンスをリフレッシュしてください。サービス構成の変更、追加、および削除の詳細は、サービスの構成を参照してください。すでに変更されている構成を確認するには、構成カスタマイズの表示を参照してください。カスタム構成を削除するには、使用例 33および使用例 35を参照してください。
サイトプロファイルを作成するときには、定義された構成が、同じサービスまたはサービスインスタンスの別のサイトプロファイルで定義された構成と競合しないことを確認してください。構成の競合はどのレイヤーでも許可されていません。ある単一レイヤー内の複数のファイルで構成が競合し、その構成が上位のレイヤーでは設定されていない場合、manifest-import サービスログにはこの競合が記され、競合している構成を使用したサービスは開始されません。詳細は、競合する構成を参照してください。
マニフェストおよびプロファイルのファイルには、標準以外の場所を使用しないでください。マニフェストおよびプロファイルの標準の場所については、サービスバンドルを参照してください。
自身で使用するサービスを作成する場合、svc:/site/service_name:instance_name のようにサービス名の先頭に site を使用します。
起動メッセージングの量の指定で説明しているように、ロギングレベルの構成を除き、マスターリスタータサービスの構成 (svc:/system/svc/restarter:default) は変更しないでください。
svccfg delcust コマンドを使用する前に、同じオプションを付けて svccfg listcust コマンドを使用してください。delcust サブコマンドを実行すると、サービスの管理カスタマイズがすべて削除される可能性があります。listcust サブコマンドを使用して、delcust サブコマンドでどのカスタマイズが削除されるかを検証します。
スクリプトでは、サービスインスタンスの完全な FMRI (svc:/service_name:instance_name) を使用します。
サービス問題のトラブルシューティング
このセクションの内容は次のとおりです。
-
実行中のスナップショットへの構成変更のコミット
-
問題があると報告されたサービスの修正
-
degraded または maintenance の状態へのイスタンスの手動による遷移
-
破壊されたサービス構成リポジトリの修正
-
システムの起動時に表示または格納するメッセージングの量の構成
-
指定したマイルストーンへの遷移またはブート
-
SMF を使用したブート問題の調査
-
SMF サービスへの inetd サービスの変換
構成変更について
SMF はサービス構成リポジトリに、実行中のスナップショットのプロパティーとは別にプロパティーの変更を格納します。サービス構成を変更した場合、実行中のスナップショットにはこれらの変更は即座に反映されません。
リフレッシュ操作では、指定したサービスインスタンスの実行中のスナップショットを、編集中の構成の値で更新します。
デフォルトでは、svcprop コマンドを実行すると、実行中のスナップショットのプロパティーが表示され、svccfg コマンドを実行すると、編集中の構成のプロパティーが表示されます。プロパティー値を変更したが、構成のリフレッシュを実行していない場合、svcprop コマンドと svccfg コマンドは別々のプロパティー値を表示します。構成のリフレッシュを実行したあとでは、svcprop コマンドと svccfg コマンドは同じプロパティー値を表示します。
リブートしても実行中のスナップショットは変更されません。svcadm restart コマンドを実行しても構成はリフレッシュされません。実行中のスナップショットに構成変更をコミットするには、svcadm refresh コマンドまたは svccfg refresh コマンドを使用します。
機能低下、オフライン、または保守であるインスタンスの修復
次の記述のそれぞれに対応するサービスインスタンスの説明を表示するには、引数を付けずに svcs -x コマンドを使用します。
-
サービスは有効になっているが実行していない。
-
サービスは別の有効なサービスの実行を妨げている。
サービスの問題への対処方法は要約すると次のようになります。
-
問題を診断します。最初にサービスログファイルを表示します。
ログファイルは /var/svc/log および /system/volatile にあります。サービスログファイルはタイムスタンプおよびメソッド終了の理由を表示します。
特定のサービスのログファイルの場所は、次のコマンドで表示されます。
$ svcs -L service-name
次のコマンドは、特定のサービスについてのログファイルの終わりを表示します。
$ svcs -Lx service-name
-
問題を修正します。
-
複数のサービス障害が確認された場合、サービスログファイルのタイムスタンプを使用して、最初に発生した障害を探すことから始めます。
-
障害が発生したサービスの影響を受けた依存関係を表示するには、次のコマンドを使用します。
$ svcs -l service-name
service-name が依存するサービスを表示するには、次のコマンドを使用します。
$ svcs -d service-name
-
問題の修正にサービス構成の変更が含まれる場合、サービスをリフレッシュします。
-
-
影響を受けたサービスを実行中の状態に移します。
保守状態のインスタンスの修復方法
保守状態のサービスインスタンスは有効になっていますが、実行できません。
-
インスタンスが保守状態になっている理由を特定します。
管理アクションがまだ完了していないためにインスタンスは maintenance 状態に遷移している可能性があります。インスタンスが遷移している場合、その状態は、末尾にアスタリスクが付いた maintenance* として表示されます。
障害後に再起動するように構成されているインスタンスは、非常に頻繁に再起動したため maintenance に格納されている場合があります。この場合、一貫して発生する障害の原因を判別する必要があります。
インスタンスに競合があるかインスタンスが競合するプロパティー値を持つため、インスタンスが maintenance に格納されている場合は、競合する構成を参照してください。
次の例の「State」および「Reason」行には、その起動メソッドが失敗したために pkg/depot サービスが maintenance 状態になっていることが示されています。
$ svcs -x svc:/application/pkg/depot:default (IPS Depot) State: maintenance since September 11, 2013 01:30:42 PM PDT Reason: Start method exited with $SMF_EXIT_ERR_FATAL. See: http://support.oracle.com/msg/SMF-8000-KS See: pkg.depot-config(1M) See: /var/svc/log/application-pkg-depot:default.log Impact: This service is not running.
Oracle サポートサイトにログインして、対象の予測的セルフヒーリングのナレッジ記事を確認します。この場合、記事には、ログファイルを調べて起動メソッドが失敗した理由を判断するように指示されています。svcs 出力にはログファイルの名前が示されます。ログファイルを表示する方法の詳細は、サービスログファイルの表示を参照してください。この例では、ログファイルに、起動メソッドの呼び出しと致命的なエラーメッセージが示されます。
[ Sep 11 13:30:42 Executing start method ("/lib/svc/method/svc-pkg-depot start"). ] pkg.depot-config: Unable to get publisher information: The path '/export/ipsrepos/Solaris11' does not contain a valid package repository. -
問題を修正します。
次の手順の 1 つ以上が必要になる可能性があります。
-
サービス構成を更新します。
報告された問題の修正でサービス構成の変更が必要な場合は、構成が変更されたサービスに対して svccfg refresh コマンドまたは svcadm refresh コマンドを使用します。svcprop コマンドを使用してプロパティー値を確認するか、このサービス固有のほかのテストを行なって、実行中のスナップショットで構成が更新されていることを検証します。
-
依存関係が実行していることを確認します。
svcs -x 出力の「Impact」行に、maintenance 状態のサービスに依存しているサービスが実行していないことが示されることがあります。svcs -l コマンドを使用して、依存サービスの現在状態を確認します。すべての必要な依存関係が実行していることを確認します。svcs -x コマンドを使用し、すべての有効なサービスが実行していることを検証します。
-
契約プロセスが停止していることを確認します。
maintenance 状態のサービスが契約サービスである場合、このサービスが開始したすべてのプロセスが停止していないかどうかを判断します。契約サービスインスタンスが保守状態である場合、次の例に示すように、契約 ID は空白にする必要があり、その契約に関連付けられたすべてのプロセスを停止している必要があります。svcs -l または svcs -o ctid を使用して、保守状態のサービスインスタンスについて契約が存在していないことを確認します。svcs -p を使用して、このサービスインスタンスに関連付けられたすべてのプロセスがまだ実行しているかどうかを確認します。保守状態のサービスインスタンスについて svcs -p で示されたプロセスはすべて、強制終了する必要があります。
$ svcs -l system-repository fmri svc:/application/pkg/system-repository:default name IPS System Repository enabled true state maintenance next_state none state_time September 17, 2013 07:18:19 AM PDT logfile /var/svc/log/application-pkg-system-repository:default.log restarter svc:/system/svc/restarter:default contract_id manifest /lib/svc/manifest/application/pkg/pkg-system-repository.xml dependency require_all/error svc:/milestone/network:default (online) dependency require_all/none svc:/system/filesystem/local:default (online) dependency optional_all/error svc:/system/filesystem/autofs:default (online)
-
サービス構成を更新します。
-
インスタンスが修復されたことをリスタータに通知します。
報告された問題が修正されたら、svcadm clear コマンドを使用して、サービスを online 状態に戻します。maintenance 状態のサービスの場合、clear サブコマンドが、サービスが修復されたことをそのサービスのリスタータに通知します。
$ svcadm clear pkg/depot:default
-s オプションを指定した場合、svcadm コマンドは、インスタンスが online 状態に達するまで、または管理者の操作なしにインスタンスが online 状態に達せないと判断するまで待機してから戻ります。遷移を行うか、遷移を行えないと判断するまでの上限を秒単位で指定するには、-T オプションを -s オプションとともに使用します。
-
インスタンスが修復されたことを検証します。
svcs コマンドを使用して、保守状態だったサービスが現在オンラインになっていることを検証します。svcs -x コマンドを使用し、すべての有効なサービスが実行していることを検証します。
オフライン状態のインスタンスを修復する方法
オフライン状態のサービスインスタンスは有効になっていますが、実行中でも実行可能でもありません。
-
インスタンスがオフラインになっている理由を判断します。
依存関係がまだ満たされていないために、インスタンスが offline 状態に遷移している可能性があります。インスタンスが遷移している場合、その状態は offline* と表示されます。
-
問題を修正します。
-
サービスの依存関係を有効にします。
必要な依存関係が無効になっている場合は、次のコマンドを使用して有効にします。
$ svcadm enable -r FMRI
-
依存関係ファイルを修正します。
依存関係ファイルが失われていたり、読み取れない場合があります。pkg fix または pkg revert を使用して、この種の問題を修正できます。pkg(1) のマニュアルページを参照してください。
-
サービスの依存関係を有効にします。
-
必要に応じてインスタンスを再起動します。
必要な依存関係が満たされなかったためにインスタンスがオフラインだった場合、依存関係を修正または有効にすると、オフラインのインスタンスが再起動し、管理アクションを加えなくてもオンラインになることがあります。
サービスにほかの修正を行なった場合は、インスタンスを再起動してください。
$ svcadm restart FMRI
-
インスタンスが修復されたことを検証します。
svcs コマンドを使用して、オフライン状態だったインスタンスが現在オンラインになっていることを検証します。svcs -x コマンドを使用し、すべての有効なサービスが実行していることを検証します。
機能低下状態のインスタンスを修復する方法
機能低下状態のサービスインスタンスは、有効になっており実行中であるか実行可能ですが、機能が制限されています。
- インスタンスが機能低下状態になっている理由を判断します。
- 問題を修正します。
-
インスタンスをオンラインにするようにリスタータに要求します。
報告された問題が修正されたら、svcadm clear コマンドを使用して、インスタンスを online 状態に戻します。degraded 状態のインスタンスの場合、clear サブコマンドは、このインスタンスのリスタータがインスタンスを online 状態に遷移させることを要求します。
$ svcadm clear pkg/depot:default
-
インスタンスが修復されたことを検証します。
svcs コマンドを使用して、機能低下状態だったインスタンスが現在オンラインになっていることを検証します。svcs -x コマンドを使用し、すべての有効なサービスが実行していることを検証します。
機能低下または保守状態としてのインスタンスのマーキング
degraded または maintenance のどちらかの状態としてサービスインスタンスをマークできます。たとえば、アプリケーションがループでスタックしていたり、デッドロックされている場合に、これを行えます。状態変更に関する情報は、マークされたインスタンスの依存関係に伝播されるので、ほかの関連インスタンスのデバッグに役立ちます。
即座の状態変更を要求するには、-I オプションを指定します。
インスタンスに maintenance のマークを付けるときに、-t オプションを指定して、一時的な状態変更を要求できます。一時的な要求はリブートまでに限り継続します。
svcadm mark とともに -s オプションを指定すると、svcadm はインスタンスにマークを付け、インスタンスが degraded または maintenance の状態になるまで待機してから戻ります。遷移を行うか、遷移を行えないと判断するまでの上限を秒単位で指定するには、-T オプションを -s オプションとともに使用します。
リポジトリの問題の診断と修復
システムの起動時に、リポジトリデーモン svc.configd は、/etc/svc/repository.db に格納された構成リポジトリの整合性チェックを実行します。svc.configd 整合性チェックに失敗すると、svc.configd デーモンは次のようなメッセージをコンソールに書き出します。
svc.configd: smf(5) database integrity check of:
/etc/svc/repository.db
failed. The database might be damaged or a media error might have
prevented it from being verified. Additional information useful to
your service provider is in:
/system/volatile/db_errors
The system will not be able to boot until you have restored a working
database. svc.startd(1M) will provide a sulogin(1M) prompt for recovery
purposes. The command:
/lib/svc/bin/restore_repository
can be run to restore a backup version of your repository. See
http://support.oracle.com/msg/SMF-8000-MY for more information.
その後、svc.configd デーモンは終了します。この終了が svc.startd デーモンによって検出されると、svc.startd が sulogin を起動します。
sulogin プロンプトで Ctrl-D を入力して sulogin を入力します。svc.startd デーモンは sulogin の終了を認識して svc.configd デーモンを再起動し、これによってリポジトリがもう一度チェックされます。この再起動後に、問題が再現されなくなる可能性があります。
 | 注意 - svc.configd デーモンを直接呼び出さないでください。svc.startd デーモンは svc.configd デーモンを起動します。 |
svc.configd が整合性チェックの失敗を再度報告し、ふたたび sulogin プロンプトが表示されている場合は、要求されたファイルシステムが満杯になっていないことを確認してください。root パスワードを使用して、リモートから、または sulogin プロンプトからログインします。ルートファイルシステムと system/volatile ファイルシステムの両方に、使用できる領域があることを確認します。これらのファイルシステムのどちらかが満杯の場合、システムをクリーンアップして再度起動します。これらのファイルシステムがどちらも満杯になっていない場合は、バックアップからリポジトリを復元する方法の手順に従ってください。
サービス構成リポジトリは、次のいずれかの理由で破損されることがあります。
-
ディスク障害
-
ハードウェアのバグ
-
ソフトウェアのバグ
-
過失によるファイルの上書き
次の手順は、破損したリポジトリをバックアップコピーしたリポジトリと交換する方法を示しています。
バックアップからリポジトリを復元する方法
始める前に
| 注意 - 破損したリポジトリだけを復元します。不要な構成変更を削除する場合に、このリポジトリ復元手順を使用しないでください。構成の変更を元に戻すには、構成カスタマイズの表示、使用例 33、および使用例 35を参照してください。 |
-
ログインします。
root パスワードを使用して、リモートから、または sulogin プロンプトからログインします。
-
次のリポジトリ復元コマンドを実行します。
# /lib/svc/bin/restore_repository
このコマンドを実行すると、破壊されていないバックアップの復元に必要な手順が示されます。SMF は、リポジトリのバックアップで説明しているように、自動的にリポジトリのバックアップを作成します。
SMF は、永続および非永続構成データを保持します。これらの 2 つのリポジトリの詳細は、サービス構成リポジトリを参照してください。restore_repository コマンドは、永続リポジトリだけを復元します。restore_repository コマンドはシステムのリブートも行いますが、これにより非永続構成データは破棄されます。非永続データは、システムリブートのあとは不要になる実行時データです。
/lib/svc/bin/restore_repository コマンドが起動すると、次のようなメッセージが表示されます。
See http://support.oracle.com/msg/SMF-8000-MY for more information on the use of this script to restore backup copies of the smf(5) repository. If there are any problems which need human intervention, this script will give instructions and then exit back to your shell.
書き込み権を付けてルート (/) ファイルシステムをマウントしたあと、またはシステムがローカルゾーンである場合は、復元するリポジトリのバックアップを選択するよう求められます。
The following backups of /etc/svc/repository.db exists, from oldest to newest: ... list of backups ...
バックアップには、バックアップのタイプとバックアップが作成された時間に基づいて名前が付けられています。boot で始まっているのは、システムのブート後、リポジトリに対して最初の変更が行われる前に作成されたバックアップです。manifest_import で始まっているのは、svc:/system/manifest-import:default のプロセス終了後に作成されたバックアップです。バックアップ時間は、YYYYMMDD_HHMMSS 形式で記録されます。
-
適切な応答を入力します。
通常は、最新のバックアップオプションを選択します。
Please enter either a specific backup repository from the above list to restore it, or one of the following choices: CHOICE ACTION ---------------- ---------------------------------------------- boot restore the most recent post-boot backup manifest_import restore the most recent manifest_import backup -seed- restore the initial starting repository (All customizations will be lost, including those made by the install/upgrade process.) -quit- cancel script and quit Enter response [boot]:復元するバックアップを指定しないで Enter を押した場合は、[] で囲まれたデフォルトの応答が選択されます。-quit- を選択すると、restore_repository スクリプトが終了して、シェルスクリプトに戻ります。
注意 - -seed- を選択すると、seed リポジトリが復元されます。このリポジトリは、初期インストールとアップグレード時に使用する目的で作成されたものです。ほかのサービス構成変更またはバックアップサービスリポジトリが機能していない場合、回復の目的に seed リポジトリだけを使用します。パッケージのインストールまたは更新でもたらされた Oracle Solaris の基本機能に対する変更を含め、すべての構成変更が失われます。seed リポジトリを回復の目的で使用するのは、最後の手段にしてください。
復元するバックアップを選択したあとで、そのバックアップが検証され、その整合性がチェックされます。なんらかの問題が検出されると、restore_repository コマンドによってエラーメッセージが出力され、別の選択を行うように促されます。有効なバックアップを選択すると、次の情報が出力され、最終確認を入力するよう促されます。
After confirmation, the following steps will be taken: svc.startd(1M) and svc.configd(1M) will be quiesced, if running. /etc/svc/repository.db -- renamed --> /etc/svc/repository.db_old_YYYYMMDD_HHMMSS /system/volatile/db_errors -- copied --> /etc/svc/repository.db_old_YYYYMMDD_HHMMSS_errors repository_to_restore -- copied --> /etc/svc/repository.db and the system will be rebooted with reboot(1M). Proceed [yes/no]? -
yes と入力して障害を修復します。
restore_repository コマンドが表示されたアクションをすべて実行すると、システムがリブートします。
起動メッセージングの量の指定
デフォルトでは、システムブート中に起動した各サービスは、コンソールにメッセージを表示しません。コンソールに表示するメッセージと、svc.startd ログファイルに記録するだけのメッセージを変更するには、次のいずれかの方法を使用します。logging-level の値には、下の表に示したいずれかの値を指定できます。
-
SPARC システムをブートするときに、ok プロンプトで boot コマンドに -m オプションを指定します。kernel(1M) のマニュアルページのメッセージオプションのセクションを参照してください。
ok boot -m logging-level
-
x86 システムをブートするときに、GRUB メニューを編集して -m オプションを指定します。Oracle Solaris 11.3 システムのブートとシャットダウン の ブート時に GRUB メニューを編集してカーネル引数を追加するおよび kernel(1M) のマニュアルページの「メッセージオプション」を参照してください。
-
システムをリブートする前に、svccfg コマンドを使用して、options/logging プロパティーの値を変更します。このプロパティーがこのシステムで変更されたことがない場合は終了せず、ユーザーがこれを追加する必要があります。次の例では、詳細メッセージングに変更します。この変更は、svc.startd デーモンを次回再起動するときに有効になります。
$ svccfg -s system/svc/restarter:default listprop options/logging $ svccfg -s system/svc/restarter:default addpg options application $ svccfg -s system/svc/restarter:default setprop options/logging=verbose $ svccfg -s system/svc/restarter:default listprop options/logging options/logging astring verbose
|
ブート先の SMF マイルストーンの指定
システムをブートするときに、ブート先の SMF マイルストーンを指定できます。
デフォルトでは、general/enabled プロパティーの値が true であるすべてのサービスがシステムのブート時に起動されます。システムのブート先のマイルストーンを変更するには、次のいずれかの方法を使用します。milestone の値には、表 3に示すように、マイルストーンサービスの FMRI またはキーワードを指定できます。
-
SPARC システムをブートするときに、ok プロンプトで boot コマンドに -m オプションを指定します。kernel(1M) のマニュアルページの -m オプションを参照してください。
ok boot -m milestone=milestone
-
x86 システムをブートするときに、GRUB メニューを編集して -m オプションを指定します。Oracle Solaris 11.3 システムのブートとシャットダウン の ブート時に GRUB メニューを編集してカーネル引数を追加するおよび kernel(1M) のマニュアルページの -m オプションを参照してください。
-
システムのリブート前に、-d オプションを付けて svcadm milestone コマンドを使用します。-d オプションを付けても付けなくても、このコマンドは実行中のサービスを即座に制限して復元することに注意してください。-d オプションを使用した場合、このコマンドはまた、指定したマイルストーンをデフォルトのブートマイルストーンに設定します。この新しいデフォルトは、リブートのあとも持続します。
$ svcadm milestone -d milestone
このコマンドは、システムの現在の実行レベルを変更しません。システムの現在の実行レベルを変更するには、init コマンドを使用します。
-s オプションを指定した場合、svcadm はマイルストーンを変更し、指定されたマイルストーンへの遷移が完了するまで待機してから戻ります。svcadm コマンドは、すべてのインスタンスが、指定したマイルストーンに達するために必要な状態に遷移したとき、または遷移を行うために管理者の操作が必要であると判断したときに戻ります。-s オプションとともに -T オプションを使用して、マイルストーンの変更操作を完了するか戻るまでの上限を秒単位で指定します。
次の表では、対応する Oracle Solaris 実行レベルを含め、SMF ブートマイルストーンについて説明します。システムの実行レベルによって、ユーザーが利用できるサービスおよびリソースが定まります。システムが一度に持つことのできる実行レベルは 1 つだけです。実行レベルの詳細については、Oracle Solaris 11.3 システムのブートとシャットダウン の 実行レベルの動作、inittab(4)のマニュアルページ、および/etc/init.d/README ファイルを参照してください。SMF ブートマイルストーンの詳細は、svcadm(1M)のマニュアルページの milestone サブコマンドを参照してください。
|
システムが現在ブートされているマイルストーンを判断するには、svcs コマンドを使用します。次の例では、システムは実行レベル 3 (milestone/multi-user-server) にブートされています。
$ svcs 'milestone/*' STATE STIME FMRI online 9:08:05 svc:/milestone/unconfig:default online 9:08:06 svc:/milestone/config:default online 9:08:07 svc:/milestone/devices:default online 9:08:25 svc:/milestone/network:default online 9:08:31 svc:/milestone/single-user:default online 9:08:51 svc:/milestone/name-services:default online 9:09:13 svc:/milestone/self-assembly-complete:default online 9:09:23 svc:/milestone/multi-user:default online 9:09:24 svc:/milestone/multi-user-server:default
SMF を使用したシステムブート問題の調査
このセクションでは、システムがブート中にハングアップした場合、または主要サービスがブート中に起動できなかった場合に行うアクションについて説明します。
システムブート時のサービスの起動に関する問題を調査する方法
システムブートでサービスを起動するときに問題が発生した場合、ブート中にシステムがハングアップすることがあります。この手順では、ブート時に発生するサービス問題を調査する方法を示します。
-
どのサービスも起動しないでブートします。
次のコマンドを実行すると、svc.startd デーモンはすべてのサービスを一時的に無効にし、コンソール上で sulogin を起動します。
ok boot -m milestone=none
boot -m コマンドとともに使用できる SMF マイルストーンのリストについては、ブート先の SMF マイルストーンの指定を参照してください。
- システムに root としてログインします。
-
すべてのサービスを有効にします。
# svcadm milestone all
-
ブートプロセスがどこでハングアップするのかを確認します。
ブートプロセスがハングアップしたら、動作していないサービスを確認するために、svcs -a を実行します。/var/svc/log のログファイル内でエラーメッセージの有無を確認します。
-
問題が解決したら、すべてのサービスが起動していることを確認します。
-
必要なサービスがすべてオンラインになっていることを確認します。
# svcs -x
-
console-login サービスの依存関係に問題がないことを確認します。
このコマンドを使えば、コンソール上の login プロセスが実行されるかどうかを確認できます。
# svcs -l system/console-login:default
-
必要なサービスがすべてオンラインになっていることを確認します。
- 通常のブートプロセスを継続します。
ブート中にローカルファイルシステムサービスが失敗した場合に、シングルユーザーログインを強制する方法
システムのブートに必要でないローカルファイルシステムは、svc:/system/filesystem/local:default サービスによってマウントされます。それらのすべてのファイルシステムをマウントできない場合、filesystem/local サービスは保守状態になります。システムの起動は続行し、filesystem/local に依存していないサービスが起動します。filesystem/local サービスへの必要な依存関係があるサービスは起動しません。
次の手順では、サービスで障害が発生した場合に、システムの起動の続行を許可する代わりに、ただちに sulogin プロンプトを表示するようシステムの構成を変更する方法について説明します。
-
system/console-login サービスを変更します。
$ svccfg -s svc:/system/console-login svc:/system/console-login> addpg site,filesystem-local dependency svc:/system/console-login> setprop site,filesystem-local/entities = fmri: svc:/system/filesystem/local svc:/system/console-login> setprop site,filesystem-local/grouping = astring: require_all svc:/system/console-login> setprop site,filesystem-local/restart_on = astring: none svc:/system/console-login> setprop site,filesystem-local/type = astring: service svc:/system/console-login> end
-
サービスをリフレッシュします。
$ svcadm refresh console-login
system/filesystem/local:default サービスで障害が発生したときは、svcs -vx コマンドを使用して障害を特定してください。障害が修正されたあと、次のコマンドを使用してエラー状態をクリアし、システムブートが続行できるようにします。
$ svcadm clear filesystem/local