この章では、サービス管理機能 (SMF) の概要について説明します。さらに、実行レベルについても説明します。
この章の内容は次のとおりです。
SMF に関連する手順については、「サービスの管理 (作業マップ)」を参照してください。実行レベルに関連する手順については、「実行制御スクリプトの使用 (作業マップ)」を参照してください。
SMF は、従来の UNIX の起動スクリプト、init 実行レベル、および構成ファイルを補強するインフラストラクチャーを提供します。SMF には、次の機能が備わっています。
管理エラー、ソフトウェアのバグ、修復不可能なハードウェアエラーなどの原因によって失敗したサービスを、依存関係の順番に自動的に再起動します。依存関係の順番は依存記述で定義されます。
表示可能なサービスオブジェクトを新しいコマンド svcs を使って作成したり、管理可能なサービスオブジェクトをコマンド svcadm と svccfg を使って作成したりします。SMF サービスおよび従来の init.d スクリプトのどちらにおいても、svcs -p を使用すると、サービスとプロセスの関係を表示することができます。
サービス構成のスナップショットを自動的に取ることで、バックアップ、復元、およびサービスへの変更の取り消しを容易にします。
サービスが実行できない原因を svcs -x で明らかにし、デバッグおよびサービスに関する質問を容易にします。また、この処理は、各サービスの個別の永続的なログファイルを使用するとより楽に行えます。
svcadm を使用してサービスを有効化および無効化します。この変更は、更新後やリブート後も維持できます。-t オプションを使用した場合、変更は一時的です。
ルート以外のユーザーに対して管理者がタスクを安全に委任する機能を拡張します。この機能には、プロパティーの変更と、システムのサービスの有効化、無効化、および再起動とが含まれます。
大規模システムにおけるブートを高速化します。これは、サービス間の依存関係に従って各サービスを並列的に起動することで実現しています。シャットダウン時にはその逆の処理が実行されます。
ブートコンソールの出力をカスタマイズして、表示を最小限にする (デフォルト) か、表示を多くする (boot -m verbose を使用) かを選択できます。
可能な場合には既存の管理業務との互換性を維持します。たとえば、顧客および ISV から提供される rc スクリプトの大部分は、通常どおり動作します。
「依存記述」では、サービス間の関係を定義します。これらの関係を使用すると、すべてのサービスを再起動するのではなく、障害の影響を直接受けているサービスのみを再起動することにより、障害を的確に封じ込めることができます。依存記述のもう 1 つの利点は、スケーラブルで再現可能な初期化プロセスを実現できることです。また、依存性をすべて定義することにより、独立したすべてのサービスを並列に起動できるため、今日の高並列マシンをうまく利用することができます。
SMF では、管理者がサービスに対して呼び出すことのできる一連のアクションを定義します。これらのアクションには、有効化、無効化、再表示、再起動、維持などがあります。各サービスは、管理アクションを実行するサービスリスタータによって管理されます。通常、アクションを実行する場合、リスタータはサービスに対していくつかのメソッドを実行します。各サービスのメソッドは、サービス構成リポジトリで定義されます。リスタータは、これらのメソッドを使って、サービスをある状態から別の状態へ移行できます。
サービス構成リポジトリでは、フォールバックができるように、各サービスが正常に起動されたときにサービスごとのスナップショットを取ります。また、リポジトリを使用すると、一貫した永続的な方法でサービスを有効または無効にしたり、サービスの状態を一貫して表示したりできます。この機能は、サービスの構成に関する問題を修正するのに役立ちます。
SMF が提供する機能のほとんどが、ユーザーの目に触れることなく実行されます。それ以外の機能には新しいコマンドでアクセスします。動作に関する可視的な変更は次のとおりです。
ブートプロセスで生成されるメッセージが少なくなりました。デフォルトでは、サービスの起動時にメッセージは表示されません。ブートメッセージによって提供されていた情報は、/var/svc/log にある各サービス用のログファイルで提供されるようになりました。ブートの問題の診断には svcs コマンドが役立ちます。なお、boot コマンドで -v オプションを使用すれば、ブートプロセス中に各サービスが起動されるたびにメッセージが生成されます。
サービスは可能なかぎり自動的に再起動されるため、プロセスを終了させないように見えます。サービスに障害があれば保守モードに切り替わりますが、通常、対応するプロセスを強制終了してもサービスは再起動されます。SMF サービスが実行されないようにするには、svcadm コマンドを使用してそのプロセスを停止する必要があります。
/etc/init.d および /etc/rc*.d のスクリプトが多数削除されました。サービスの有効化および無効化に、これらのスクリプトはもう必要ありません。/etc/inittab のエントリも削除され、サービスの管理に SMF が使用できるようになりました。ISV によって提供されるスクリプトおよび inittab エントリ、あるいはローカルで開発されたそれらは、従来どおり機能します。ブートプロセス中で、これらのサービスが起動される時点が以前と異なる可能性がありますが、必ず SMF サービスのあとに起動されるため、サービス依存関係に問題は起きません。
この節では、SMF フレームワーク内で使われる用語とその定義をいくつか紹介します。これらの用語は、マニュアル全体で使用されます。SMF の概念を理解するには、これらの用語を理解する必要があります。
SMF フレームワークでの基本的な管理単位は「サービスインスタンス」です。それぞれの SMF サービスでは、構成された複数のバージョンを保持することができます。さらに、1 つの Oracle Solaris システム上で同じバージョンの複数のインスタンスが動作できます。「インスタンス」とは、サービスの特定の構成のことです。 Web サーバーはサービスです。ポート 80 で待機するよう構成された Web サーバーデーモンはインスタンスです。Web サーバーサービスの各インスタンスには、異なる構成要件を設定できます。サービスにはシステム全体の構成要件が設定されていますが、各インスタンスでは必要に応じて特定の要件を無効にできます。1 つのサービスの複数のインスタンスは、サービスオブジェクトの子オブジェクトとして管理されます。
サービスは、in.dhcpd や nfsd などの標準の長年続いているシステムサービスだけではなく、Oracle ソフトウェアなどの ISV アプリケーションを含むさまざまなシステムエンティティーも意味します。また、次のような今まであまり使われなかったエンティティーを組み込むこともできます。
物理ネットワークデバイス
IP アドレス構成
カーネル構成情報
マルチユーザー実行レベルなど、システムの init 状態に対応するマイルストン
一般に、サービスはアプリケーションやほかのサービス (ローカルやリモート) に機能リストを提供するエンティティーです。サービスは、暗黙のうちに宣言されたローカルサービスのリストに依存しています。
「マイルストン」とは、特殊なタイプのサービスです。マイルストンサービスは、システムの高レベルの属性を表します。たとえば、実行レベル S、2、および 3 を構成するサービスはマイルストンサービスによってそれぞれ表されます。
各サービスインスタンスの名前は、障害管理リソース識別子 (FMRI) によって付けられます。FMRI には、サービス名とインスタンス名が含まれます。たとえば、rlogin サービスの FMRI は svc:/network/login:rlogin となり、ここでの network/login はサービスを、rlogin はサービスインスタンスをそれぞれ示します。
次の FMRI の形式はどれも同じです。
svc://localhost/system/system-log:default
svc:/system/system-log:default
system/system-log:default
また、SMF コマンドの中には、 svc:/system/system-log という FMRI 形式を使用できるものや、あいまいさがまったくない場合に、使用するインスタンスを推測するものもあります。適切な FMRI 形式を判断する方法については、svcadm(1M) や svcs(1) などの SMF コマンドのマニュアルページを参照してください。
通常、サービス名には一般的な機能カテゴリが含まれます。カテゴリには、次のものがあります。
application
デバイス
milestone
network
platform
site
system
また、従来の init.d スクリプトは、svc ではなく lrc で始まる FMRI (たとえば、lrc:/etc/rcS_d/S35cacheos_sh) で表現されます。従来のサービスは、SMF を使用して監視できますが、管理することはできません。
SMF を使用してシステムを初めてブートしたときに、/etc/inetd.conf に示されたサービスが自動的に SMF サービスに変換されます。これらのサービスの FMRI は多少異なります。変換された inetd サービスの構文は次のとおりです。
network/<service-name>/<protocol> |
また、RPC プロトコルを使用するサービスの構文は次のとおりです。
network/rpc-<service-name>/rpc_<protocol> |
ここで、<service-name> は /etc/inetd.conf に定義されている名前であり、<protocol> はそのサービスに使用されるプロトコルです。たとえば、rpc.cmsd サービスの FMRI は network/rpc-100068_2-5/rpc_udp となります。
svcs コマンドは、サービスインスタンスの状態、開始時刻、および FMRI を表示します。各サービスの状態は次のいずれかになります。
degraded – サービスインスタンスは有効ですが、限られた能力で実行されています。
disabled – サービスインスタンスは無効で、実行されていません。
legacy_run – 従来のサービスは SMF によって管理されませんが、監視することはできます。この状態は従来のサービスでのみ使用されます。
maintenance – サービスインスタンスに、管理者が解決しなければならないエラーが発生しました。
offline – サービスインスタンスは有効ですが、サービスが実行されていないか、利用できる状態にありません。
online – サービスインスタンスは有効で、正常に起動されました。
uninitialized – この状態は、すべてのサービスの構成が読み込まれる前の初期状態です。
SMF の「目録」とは、サービスまたはサービスインスタンスに関連付けられた完全なプロパティーセットを含む XML ファイルのことです。これらのファイルは /var/svc/manifest に格納されます。目録は、サービスプロパティーの変更には使用しないでください。サービス構成リポジトリは、信頼できる構成情報ソースです。情報を目録からリポジトリに取り込むには、svccfg import を実行するか、システムのブート時に、サービスが情報をインポートできるようにする必要があります。
SMF 目録の詳しい内容については、service_bundle(4) のマニュアルページを参照してください。サービスのプロパティーを変更する必要がある場合には、svccfg(1M) または inetadm(1m) のマニュアルページを参照してください。
SMF の「プロファイル」とは、サービスインスタンスの一覧とそれぞれを有効にするかどうかを示す XML ファイルのことです。この Oracle Solaris リリースで配布されるプロファイルには、次のようなものがあります。
/var/svc/profile/generic_open.xml – このプロファイルは、以前の Solaris リリースではデフォルトで起動されていた標準のサービスを有効化します。
/var/svc/profile/generic_limited_net.xml – このプロファイルは、以前の Solaris リリースではデフォルトで起動されていた標準のインターネットサービスの多くを無効化します。ネットワーク接続を提供するために network/ssh サービスは有効化されます。
/var/svc/profile/ns_*.xml – これらのプロファイルは、システムで実行されるよう設定されているネームサービスに関連するサービスを有効化します。
/var/svc/profile/platform_*.xml – これらのプロファイルは、特定のハードウェアプラットフォームに関連するサービスを有効化します。
Oracle Solaris OS を新規にインストールした場合やこの OS にアップグレードした場合は、そのあとの最初のブート時に、いくつかの Solaris プロファイルが自動的に適用されます。具体的には、/var/svc/profile/generic.xml プロファイルが適用されます。通常、このファイルには、generic_open.xml または generic_limited_net.xml へのシンボリックリンクが設定されています。また、最初のブート時に site.xml というプロファイルが /var/svc/profile に存在している場合や、次のブートまでに追加された場合は、このプロファイルの内容が適用されます。管理者は site.xml プロファイルを使用して、有効にするサービスの初期セットをカスタマイズすることができます。
プロファイルの使用方法については、「SMF プロファイルを適用する方法」を参照してください。
「サービス構成リポジトリ」には、永続的な構成情報と SMF 実行時サービスデータが格納されます。リポジトリは、ローカルメモリーとローカルファイルの間で割り当てられます。SMF は、最終的にサービスデータをネットワークディレクトリサービスで表現できるように設計されています。ネットワークディレクトリサービスはまだ利用できません。サービス構成リポジトリ内のデータを使用すると、多数の Solaris インスタンス間で構成情報の共有や管理の簡素化ができます。サービス構成リポジトリは、SMF インタフェースを使ってのみ操作または照会できます。リポジトリの操作やアクセスの方法については、svccfg(1M) および svcprop(1) のマニュアルページを参照してください。サービス構成リポジトリデーモンについては、svc.configd(1M) のマニュアルページを参照してください。サービス構成ライブラリについては、libscf(3LIB) のマニュアルページを参照してください。
SMF では、次に示すリポジトリのバックアップを自動的に行います。
ブートバックアップは、システムを起動するたびに、リポジトリに対する最初の変更が行われる直前に行われます。
manifest_import バックアップは、svc:/system/manifest-import:default によって新しい目録がインポートされたりアップグレードスクリプトが実行されたりした場合、このサービスの完了後に行われます。
タイプごとに 4 つのバックアップがシステムによって管理されます。必要に応じて、もっとも古いバックアップから削除されます。バックアップは /etc/svc/repository -type-YYYYMMDD_HHMMSWS という名前で格納されます。ここでの YYYYMMDD (年、月、日) と HHMMSS (時、分、秒) は、バックアップが行われた日時です。時間は 24 時間形式で表されます。
エラーが発生した場合は、これらのバックアップからリポジトリを復元できます。そのためには、/lib/svc/bin/restore_repository コマンドを使用します。詳細は、「破壊されたリポジトリを修復する方法」を参照してください。
サービス構成リポジトリ内のデータには、編集可能な構成情報のほかに「スナップショット」もあります。各サービスインスタンスに関するデータは、スナップショットに格納されます。標準のスナップショットは、次のとおりです。
initial – 目録の最初のインポート時に取られる
running – サービスメソッドが実行されるときに使用される
start – 最後に起動が成功したときに取られる
SMF サービスは常に running スナップショットを使って実行します。このスナップショットが存在しない場合は、自動的に作成されます。
svcadm refresh コマンド (ときどきこのあとに svcadm restart コマンドが実行される) によってスナップショットがアクティブになります。以前のスナップショットに含まれるインスタンス構成を表示したり、そこに戻ったりするには、svccfg コマンドを使用します。詳細については、「別の SMF スナップショットに戻す方法」を参照してください。
この節では、SMF の使用時に利用できるインタフェースについて簡単に説明します。
SMF には、SMF とやりとりしたり、標準の管理タスクを実行したりする 1 連のコマンド行ユーティリティーが用意されています。SMF の管理には、次のユーティリティーを使用できます。
表 18–1 サービス管理機能のユーティリティー
コマンド名 |
機能 |
---|---|
inetadm | |
svcadm | |
svccfg | |
svcprop | |
svcs |
SMF には、svc.configd デーモンを介してサービス構成リポジトリとのやりとりを行うための一連のプログラミングインタフェースが用意されています。このデーモンは、ローカルのリポジトリデータストアに対するすべての要求を判定します。サービス構成リポジトリ内のサービスとの最低レベルのやりとりの手段として、1 連の基本的なインタフェースが定義されています。これらのインタフェースを使うと、トランザクションやスナップショットなどのサービス構成リポジトリのすべての機能にアクセスできます。
多くの開発者は、SMF とやりとりするための一般的なタスクのみを必要としています。これらのタスクは、便利な機能として基本サービスの上位で実装され、実装にかかる負荷を軽減しています。
SMF には、マスターリスタータデーモンと委任リスタータがあります。
svc.startd デーモンは、Solaris OS のマスタープロセススタータおよびリスタータです。このデーモンは、システム全体のサービス依存性を管理する役割を担っています。適切な実行レベルで適切な /etc/rc*.d スクリプトを起動することは、以前は init の役割でしたが、現在はこのデーモンの役割です。まず、svc.startd はサービス構成リポジトリに格納されている情報を取り出します。次に、サービス依存性が満たされたときにそのサービスを起動します。また、失敗したサービスの再起動や、依存性が満たされなくなったサービスの停止も行います。このデーモンは、プロセスの消滅などのイベントを通してオペレーティングシステムの可用性の点からサービス状態を追跡します。
一部のサービスは、起動時に共通の動きが見られます。これらのサービス間に共通性を持たせるために、委任リスタータがこれらのサービスに対する責任を負うことがあります。また、より複雑な再起動やアプリケーション固有の再起動を行えるようにする場合にも委任リスタータを使用できます。委任リスタータは、別のメソッド群をサポートできますが、マスターリスタータと同じサービス状態をエクスポートします。リスタータの名前は、サービスとともに格納されます。委任リスタータの例には、インターネットサービスを常に実行しておくのではなく、要求に応じて起動できる inetd があります。
SMF には、システムをブートするための新しい方法が用意されています。次に例を示します。
all マイルストンに関連付けられるシステム状態が追加されています。all マイルストンでは、multi-user-server マイルストン上で定義済みの依存関係を持つすべてのサービスと、定義済みの依存関係を持たないすべてのサービスが起動されます。Sun 以外の製品など、サービスを追加しても、次のコマンドを実行するまでそれらのサービスが自動的に起動されないことがあります。
ok boot -m milestone=all |
システムをブートするときに、冗長オプションを使用して詳細なメッセージを表示することができます。デフォルトでは、これらのメッセージは表示されません。冗長モードでブートするには、次のコマンドを使用します。
ok boot -mverbose |
none マイルストンに関連付けられた新しいシステム状態が存在します。このマイルストンを使ってシステムをブートすると、init、svc.startd、 および svc.configd だけが起動されます。この状態は、ブートに関する問題のデバッグを行う際、非常に役立つ場合があります。特に、サービスが一切起動されないため、SMF サービスの設定に関する問題のデバッグがより単純になります。none マイルストンの使用手順については、「どのサービスも起動しないでブートする方法」を参照してください。
標準の Solaris サービスの多くは SMF によって管理されていますが、実行レベルの移行に対しては /etc/rc*.d 内にあるスクリプトが引き続き実行されます。以前の Solaris リリースに含まれていた /etc/rc*.d スクリプトの大半は、SMF の一環として削除されました。残りのスクリプトを引き続き実行できることにより、SMF を使用するようにサービスを変換しなくても Sun 以外のアプリケーションを追加できます。
また、/etc/inittab と /etc/inetd.conf は、インストール後のスクリプトで修正するパッケージで利用可能でした。これらは、従来の実行サービスと呼ばれます。inetconv コマンドは、これらの従来の実行サービスをサービス構成リポジトリに追加する場合に実行されます。従来の実行サービスの状態は表示できますが、ほかの変更は一切 SMF でサポートされていません。この機能を使用するアプリケーションは、SMF が提供する高精度の障害の封じ込めによるメリットを受けられません。
SMF を利用するように変換されたアプリケーションは、/etc/inittab と /etc/inetd.conf の各ファイルに対して変更を行えなくなります。変換されたアプリケーションは、/etc/rc*.d スクリプトを使用しません。また、新しいバージョンの inetd は /etc/inetd.conf のエントリを検索しません。
システムの「実行レベル」(「init 状態」とも呼ばれる) は、ユーザーが使用できるサービスとリソースを定義します。システムが一度に持つことのできる実行レベルは 1 つだけです。
Solaris OS には 8 つの実行レベルがあります (次の表を参照)。デフォルトの実行レベル 3 は、/etc/inittab ファイルに指定されています。
表 18–2 Solaris 実行レベル
また、svcadm コマンドを使用してシステムの実行レベルを変更することもできます。その場合は、実行するときのマイルストンを選択してください。次の表に、各マイルストンに対応する実行レベルを示します。
表 18–3 Solaris 実行レベルと SMF マイルストン
実行レベル |
SMF マイルストンの FMRI |
---|---|
S |
milestone/single-user:default |
2 |
milestone/multi-user:default |
3 |
milestone/multi-user-server:default |
ほとんどの状況下では、init コマンドといずれかの実行レベルを使用してシステムの状態を変更するだけで十分です。マイルストンを使用したシステム状態の変更は複雑であり、予期しない動作につながる可能性があります。さらに、init コマンドではシステムのシャットダウンも行えます。したがって、init が、システムの状態を変更するための最適なコマンドであると言えます。
ただし、none マイルストンによるシステムのブートは、起動時の問題のデバッグを行う際に非常に役立つ可能性があります。none マイルストンと同等の実行レベルはありません。具体的な手順については、「どのサービスも起動しないでブートする方法」を参照してください。
who -r コマンドを使用すると、実行レベルに関する情報が表示されます。
$ who -r |
システムの現在の実行レベルを調べるには、who -r コマンドを使用します。
次の例では、システムの現在の実行レベルと以前の実行レベルに関する情報を表示します。
$ who -r . run-level 3 Dec 13 10:10 3 0 S $ |
who -r コマンドの出力 |
説明 |
---|---|
run-level 3 |
現在の実行レベル |
Dec 13 10:10 |
実行レベルが最後に変更された日時 |
3 |
現在の実行レベル |
0 |
最後にリブートしてからシステムがこの実行レベルになった回数 |
S |
以前の実行レベル |
init または shutdown コマンドを使用してシステムをブートしたり、実行レベルを変更したりすると、init デーモンは /etc/inittab ファイルから情報を読み取ってプロセスを起動します。/etc/inittab ファイルには、init プロセスにとって重要な次の情報が定義されています。
init プロセスが再起動すること
起動、監視するプロセス、および停止時に再起動するプロセス
システムが新しい実行レベルに移行したとき行う処理
/etc/inittab ファイル内の各エントリは、次のフィールドからなります。
id:rstate :action:process
次の表に、inittab エントリの各フィールドを要約します。
表 18–4 inittab ファイルのフィールドの説明
フィールド |
説明 |
---|---|
id |
エントリに固有の (一意の) 識別子。 |
rstate |
このエントリが適用される実行レベルのリスト。 |
アクション |
プロセスフィールドに指定されたプロセスの実行方法。指定できる値は、 sysinit、boot、bootwait、wait、および respawn です。 ほかの action キーワードについては、inittab(4) のマニュアルページを参照してください。 |
process |
実行するコマンドまたはスクリプトを定義します。 |
次の例では、Solaris リリースでインストールされるデフォルトの inittab ファイルを示します。そのあとに、この例の出力の各行についての説明も示します。
ap::sysinit:/sbin/autopush -f /etc/iu.ap (1) sp::sysinit:/sbin/soconfig -f /etc/sock2path (2) smf::sysinit:/lib/svc/bin/svc.startd >/dev/msglog 2<>/dev/msglog (3) p3:s1234:powerfail:/usr/sbin/shutdown -y -i5 -g0 >/dev/msglog 2<>/dev/...(4) |
STREAMS モジュールを初期化します
ソケット転送プロバイダを構成します
SMF 用のマスターリスタータを初期化します
電源障害の場合のシャットダウンを指定します
init プロセスが起動されます。init プロセスは、/etc/default/init ファイルを読み取って環境変数を設定します。デフォルトでは、TIMEZONE 変数だけが設定されます。
init は inittab ファイルを読み取り、次の処理を行います。
action フィールドが sysinit になっているすべてのプロセスエントリを実行して、ユーザーがログインする前に特別な初期設定処理がすべて行われるようにします。
起動アクティビティーを svc.startd に渡します。
init プロセスが inittab ファイルを使用する方法については、init(1M) のマニュアルページを参照してください。