この付録では、次のことに関するベストプラクティスおよびトラブルシューティングについて説明します。
機能低下、オフライン、または保守状態になっているサービスインスタンスの修復
SMF リポジトリの問題の診断と修復
SMF 起動メッセージングの量の指定
ブートする SMF マイルストーンの指定
システムブート問題の調査
SMF サービスへの inetd サービスの変換
ほとんどのサービスは構成ポリシーを記述します。必要な構成が実装されていない場合は、サービスを変更してポリシーの説明を変更してください。サービスプロパティーの値を変更するか、別のプロパティー値で新しいサービスインスタンスを作成します。サービスインスタンスを無効にして、SMF サービスで管理する予定の構成ファイルを編集しないでください。Oracle Solaris の増加している基本機能は SMF サービスプロパティーで構成され、構成ファイルを編集して構成するわけではありません。
Oracle またはサードパーティーソフトウェアベンダーから提供されるマニフェストおよびシステムプロファイルは、変更しないでください。これらのマニフェストおよびプロファイルは、システムをアップグレードするときに置き換えられ、これらのファイルに加えた変更は失われます。代わりに、次のいずれかを行います。
サービスインスタンスの追加の説明に従って、別のプロパティー値を持つ新しいサービスインスタンスを追加します。
サービスをカスタマイズするためのプロファイルを作成します。svcbundle コマンドまたは svccfg extract コマンドを使用して、プロファイルファイルを作成します。そのファイルのプロパティー値をカスタマイズして、それぞれのカスタマイズの理由に関するコメントを含めます。プロファイルファイルを適切な /etc/svc/profile サブディレクトリにコピーし、manifest-import サービスを再起動します。
複数のシステムに同じカスタム構成を適用するには、各システム上の同じ /etc/svc/profile サブディレクトリに同じプロファイルファイルをコピーし、各システムで manifest-import サービスを再起動します。各システムへのプロファイルの配信を自動化するには、プロファイルをパッケージ化します。複数のシステムの構成を参照してください。
svccfg コマンドまたは inetadm コマンドを使用して、プロパティーを直接操作します。svccfg コマンドを使用してプロパティー値を変更する場合は、必ず、構成変更についての説明に従ってサービスインスタンスをリフレッシュしてください。サービス構成の変更、追加、および削除の詳細は、サービスの構成を参照してください。すでに変更されている構成を確認するには、構成カスタマイズの表示を参照してください。カスタム構成を削除するには、使用例 40, カスタマイズの削除および使用例 42, 構成のマスク解除を参照してください。
カスタムプロファイルを作成する場合は、定義される構成が、同じサービスまたはサービスインスタンスの別のマニフェストまたはプロファイルの同じレイヤーで定義されている構成と競合していないことを確認してください。構成の競合はどのレイヤーでも許可されていません。ある単一レイヤー内の複数のファイルで構成が競合し、その構成が上位のレイヤーでは設定されていない場合、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 コマンドを引数なしで使用します。
サービスは有効になっているが実行していない。
サービスは有効になっているが、通常の容量で実行されていない。
サービスは別の有効なサービスの実行を妨げている。
サービスは無効になっているが、disabled 状態への移行を完了できない。
サービスの問題への対処方法は要約すると次のようになります。
問題を診断します。最初にサービスログファイルを表示します。
ログファイルは /var/svc/log および /system/volatile にあります。サービスログファイルはタイムスタンプおよびメソッド終了の理由を表示します。
特定のサービスのログファイルの場所は、次のコマンドで表示されます。
$ svcs -L service-name
次のコマンドは、特定のサービスについてのログファイルの終わりを表示します。
$ svcs -Lx service-name
問題を修正します。
複数のサービス障害が確認された場合、サービスログファイルのタイムスタンプを使用して、最初に発生した障害を探すことから始めます。
障害が発生したサービスの影響を受けた依存関係を表示するには、次のコマンドを使用します。
$ svcs -l service-name
service-name が依存するサービスを表示するには、次のコマンドを使用します。
$ svcs -d service-name
問題の修正にサービス構成の変更が含まれる場合、サービスをリフレッシュします。
影響を受けたサービスを実行中の状態に移します。
保守状態にあるサービスインスタンスが有効になっているが、実行できないか、または無効になっているが、disabled 状態への移行を完了できません。
管理アクションがまだ完了していないためにインスタンスは maintenance 状態に遷移している可能性があります。インスタンスが遷移している場合、その状態は、末尾にアスタリスクが付いた maintenance* として表示されます。
障害後に再起動するように構成されているインスタンスは、非常に頻繁に再起動したため maintenance に格納されている場合があります。この場合、一貫して発生する障害の原因を判別する必要があります。
インスタンスに競合があるかインスタンスが競合するプロパティー値を持つため、インスタンスが maintenance に格納されている場合は、競合する構成を参照してください。
このインスタンスは、インスタンスが無効にされたが、stop メソッドが失敗したため disabled 状態に到達できないために 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(8) 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 コマンドを使用して、インスタンスが修復されたことをそのサービスのリスタータに通知します。SMF はインスタンスを、それが構成された状態に移行しようとします。インスタンスが有効になっている場合、SMF はインスタンスをオンラインにしようとします。インスタンスが無効になっている場合、SMF はそのインスタンスを disabled 状態に移行します。
$ 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(7) 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(8) will provide a sulogin(8) 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 ファイルシステムの両方に、使用できる領域があることを確認します。これらのファイルシステムのどちらかが満杯の場合、システムをクリーンアップして再度起動します。これらのファイルシステムがどちらも満杯になっていない場合は、バックアップからリポジトリを復元する方法の手順に従ってください。
サービス構成リポジトリは、次のいずれかの理由で破損されることがあります。
ディスク障害
ハードウェアのバグ
ソフトウェアのバグ
過失によるファイルの上書き
次の手順は、破損したリポジトリをバックアップコピーしたリポジトリと交換する方法を示しています。
始める前に
注意 - 破損したリポジトリだけを復元します。不要な構成変更を削除する場合に、このリポジトリ復元手順を使用しないでください。構成の変更を元に戻すには、構成カスタマイズの表示、使用例 40, カスタマイズの削除、および使用例 42, 構成のマスク解除を参照してください。 |
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(7) 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(8) and svc.configd(8) 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(8). Proceed [yes/no]?
restore_repository コマンドが表示されたアクションをすべて実行すると、システムがリブートします。
デフォルトでは、システムブート中に起動した各サービスは、コンソールにメッセージを表示しません。コンソールに表示するメッセージと、svc.startd ログファイルに記録するだけのメッセージを変更するには、次のいずれかの方法を使用します。logging-level の値には、下の表に示したいずれかの値を指定できます。
SPARC システムをブートするときに、ok プロンプトで boot コマンドに -m オプションを指定します。kernel(8) のマニュアルページの「メッセージオプション」を参照してください。
ok boot -m logging-level
x86 システムをブートするときに、GRUB メニューを編集して -m オプションを指定します。Oracle Solaris 12 システムのブートとシャットダウン の Adding Kernel Arguments at Boot Timeおよび kernel(8) のマニュアルページの「メッセージオプション」を参照してください。
システムをリブートする前に、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 マイルストーンを指定できます。
デフォルトでは、general/enabled プロパティーの値が true であるすべてのサービスがシステムのブート時に起動されます。システムのブート先のマイルストーンを変更するには、次のいずれかの方法を使用します。milestone の値には、図 3, 表 3, SMF ブートマイルストーンおよび対応する実行レベルに示すように、マイルストーンサービスの FMRI またはキーワードを指定できます。
SPARC システムをブートするときに、ok プロンプトで boot コマンドに -m オプションを指定します。kernel(8) のマニュアルページの -m オプションを参照してください。
ok boot -m milestone=milestone
x86 システムをブートするときに、GRUB メニューを編集して -m オプションを指定します。Oracle Solaris 12 システムのブートとシャットダウン の Adding Kernel Arguments at Boot Timeおよび kernel(8) のマニュアルページの -m オプションを参照してください。
システムのリブート前に、-d オプションを付けて svcadm milestone コマンドを使用します。-d オプションを付けても付けなくても、このコマンドは実行中のサービスを即座に制限して復元することに注意してください。-d オプションを使用した場合、このコマンドはまた、指定したマイルストーンをデフォルトのブートマイルストーンに設定します。この新しいデフォルトは、リブートのあとも持続します。
$ svcadm milestone -d milestone
このコマンドは、システムの現在の実行レベルを変更しません。システムの現在の実行レベルを変更するには、init コマンドを使用します。
-s オプションを指定した場合、svcadm はマイルストーンを変更し、指定されたマイルストーンへの遷移が完了するまで待機してから戻ります。svcadm コマンドは、すべてのインスタンスが、指定したマイルストーンに達するために必要な状態に遷移したとき、または遷移を行うために管理者の操作が必要であると判断したときに戻ります。-s オプションとともに -T オプションを使用して、マイルストーンの変更操作を完了するか戻るまでの上限を秒単位で指定します。
次の表では、対応する Oracle Solaris 実行レベルを含め、SMF ブートマイルストーンについて説明します。システムの実行レベルによって、ユーザーが利用できるサービスおよびリソースが定まります。システムが一度に持つことのできる実行レベルは 1 つだけです。実行レベルの詳細については、Oracle Solaris 12 システムのブートとシャットダウン の How Run Levels Work、inittab(5)のマニュアルページ、および/etc/init.d/README ファイルを参照してください。SMF ブートマイルストーンの詳細は、svcadm(8) のマニュアルページの 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
このセクションでは、システムがブート中にハングアップした場合、または主要サービスがブート中に起動できなかった場合に行うアクションについて説明します。
システムブートでサービスを起動するときに問題が発生した場合、ブート中にシステムがハングアップすることがあります。この手順では、ブート時に発生するサービス問題を調査する方法を示します。
次のコマンドを実行すると、svc.startd デーモンはすべてのサービスを一時的に無効にし、コンソール上で sulogin を起動します。
ok boot -m milestone=none
boot -m コマンドとともに使用できる SMF マイルストーンのリストについては、ブート先の SMF マイルストーンの指定を参照してください。
# svcadm milestone all
ブートプロセスがハングアップしたら、動作していないサービスを確認するために、svcs -a を実行します。/var/svc/log のログファイル内でエラーメッセージの有無を確認します。
# svcs -x
このコマンドを使えば、コンソール上の login プロセスが実行されるかどうかを確認できます。
# svcs -l system/console-login:default
システムのブートに必要でないローカルファイルシステムは、svc:/system/filesystem/local:default サービスによってマウントされます。それらのすべてのファイルシステムをマウントできない場合、filesystem/local サービスは保守状態になります。システムの起動は続行し、filesystem/local に依存していないサービスが起動します。filesystem/local サービスへの必要な依存関係があるサービスは起動しません。
次の手順では、サービスで障害が発生した場合に、システムの起動の続行を許可する代わりに、ただちに sulogin プロンプトを表示するようシステムの構成を変更する方法について説明します。
$ 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