SMF の概念とコンポーネント
このセクションでは、このガイドでこれから使用する用語を定義します。
次の図に、SMF フレームワークのプライマリコンポーネントを示します。イメージをブートすると、SMF は、必要に応じてサービス構成リポジトリを更新し、リポジトリデータを読み取り、有効化されたサービスインスタンスを依存関係の正しい順序で起動します。独立したサービスは並列で起動されます。イメージを停止処理すると、依存関係の逆順序でサービスが停止処理されます。
次の図で、libscf は、リスタータがサービス構成リポジトリとのやりとりに使用するライブラリインタフェースです。サービス構成リポジトリと libscf ライブラリインタフェースとのやりとりは、svc.configd デーモンが管理します。svcs、svcprop、svcadm、および svccfg のコマンドは、管理者がサービス構成リポジトリとのやりとりに使用するインタフェースです。
図 1 サービス管理機能フレームワーク
SMF サービス
SMF サービスは、永続的に実行するアプリケーションであり、次のようなシステムエンティティーを表します。
-
データベースや Web サーバーなどのアプリケーションサービス
-
基本的なシステムサービス
-
デバイスのソフトウェア状態
-
カーネル構成情報
-
システムの即応性レベルに対応するマイルストーン
サービスインスタンスはサービスの子であり、アプリケーションとほかのサービスインスタンスに機能および依存関係をもたらします。インスタンスだけが状態を保有し、起動および停止できます。ハードウェアまたはソフトウェアの障害など何らかの理由でインスタンスが失敗した場合、SMF は自動的に障害を検出し、インスタンスと依存インスタンスを再起動します。
サービスのインスタンスでは、サービスの複数の構成を同時に実行することができます。サービスインスタンスは、共通のサービス構成を継承してカスタマイズします。たとえば、あるインスタンスはポート 80 で待機するように構成され、別のインスタンスはポート 1008 で待機するように構成された Web サーバーサービスを定義できます。ほとんどのサービスには default インスタンスがあります。プログラムの実行ではなく構成の格納に SMF を使用するサービスなど、一部のサービスにはインスタンスはありません。たとえば、x11/x11-server サービスにはインスタンスがありません。
SMF サービスは、サービスマニフェストと呼ばれるファイルに記述されています。マニフェストには、サービスインスタンス、依存関係、構成プロパティー、およびメソッドが記述されます。サービスメソッドはサービスインスタンスの起動、停止、リフレッシュを行います。メソッドは、デーモン、ほかのバイナリ実行可能ファイル、または実行可能スクリプトの場合があります。サービスプロファイルファイルでは、主にプロパティーを追加し、プロパティー値を追加およびオーバーライドすることによって、既存のサービスをカスタマイズできます。リポジトリレイヤーで説明しているように、新しいプロパティーと値は、マニフェストで割り当てられた値の上にレイヤー化されます。マニフェストとプロファイルの詳細は、サービスバンドルを参照してください。プロファイルは、SMF プロファイルの作成で説明しているように、複数のシステムに同じカスタム構成を適用するための優れたツールでもあります。
サービス情報は、SMF データベースとも呼ばれるサービス構成リポジトリに格納されています。サービス構成リポジトリは、システム上の各サービスインスタンスの現在の状態と、サービスおよびサービスインスタンスごとの構成データを格納します。データは、リポジトリレイヤーで説明しているように、値がどのように変更されたかに応じてレイヤーに格納されます。
SMF には、有効化、無効化、リフレッシュ、再起動など、サービスインスタンスで呼び出すことのできるアクションが用意されています。各サービスインスタンスは、リスタータがこれらの管理アクションを実行することによって管理されます。通常、リスタータは、メソッドを実行してサービスインスタンスをある状態から別の状態に移行させることによってアクションを実行します。リスタータの詳細は、サービスリスタータを参照してください。
マイルストーンサービスとは、システムの init 状態などのシステムの即応性レベルを表す特殊なタイプのサービスです。マイルストーンは、ほかのサービスインスタンスが起動するときに依存するサービスです。たとえば、実行レベルは、svc:/milestone/multi-user-server などのマイルストーンサービスによって表されます。マイルストーンはまた、svc:/milestone/devices、svc:/milestone/network、svc:/milestone/name-services などのサービスグループの即応性を示すために使用することもできます。
サービスモデル
SMF サービスは、次のいずれかのモデルになります。
- 一時サービス
-
このサービスは、何らかの作業を行なったあと、長時間実行するプロセスを開始せずに終了します。
- 子または待機サービス
-
このサービスは、その子プロセスが正常に終了したときに必ず再起動します。正常に終了した子プロセスはエラーとして扱われません。
- 契約またはデーモンサービス
-
このサービスは、長時間実行するデーモンを起動するか、サービス契約の一部としてまとめられた複数の関連するプロセスを起動します。契約サービスは、開始したプロセスと、依存サービスおよびその起動順序を管理します。ユーザーによる管理が必要なのは高度なサービスだけです。
定期的なサービスは、これらのどのモデルにも適合しない特殊なケースです。定期的なサービスまたはスケジュールされているサービスは、実行時間の短いプロセスを定期的な間隔またはスケジュールされた間隔で開始し、関連付けられた契約済みプロセスが存在しない場合は次の実行までオンラインのままになります。詳細は、Oracle Solaris 11.3 でのシステムサービスの開発 の 第 3 章, 定期的に実行するサービスの作成およびOracle Solaris 11.3 でのシステムサービスの開発 の 第 4 章, 特定のスケジュールで実行するサービスの作成を参照してください。
サービス名
各サービスおよびサービスインスタンスは、障害管理リソース識別子 (FMRI) で表されます。サービスインスタンスの完全な FMRI は次の形式になります。
svc:/service_name:instance_name
service_name は、network/dns/client や application/pkg/server などの階層的な名前です。service_name の最後のスラッシュ (/) の前のコンポーネントは、サービスのカテゴリです。application、device、milestone、network、system などのカテゴリは、サービスの目的の識別に役立ちます。
site カテゴリは、ユーザー自身の SMF サービスを作成するときに名前の競合を回避できるように予約されています。たとえば、svc:/site/tool という名前のサイト固有のサービスは、svc:/tool という名前の Oracle Solaris サービスと競合しません。
サービスインスタンス名は、親サービス名にコロンに続けて付加されます。たとえば、svc:/system/identity:node および svc:/system/identity:domain は svc:/system/identity サービスのインスタンスです。
スクリプトでは、完全なサービスインスタンス名を使用することをお勧めします。対話形式では、名前は右端部分に短縮でき、これが結果的に一意の名前になります。たとえば、svc:/system/identity は identity に短縮でき、svc:/system/identity:domain は identity:domain に短縮できます。インスタンス名は、その前にサービス名の一部とコロンを置く必要があります。
サービス状態
SMF サービスは、どの時点でも、次のいずれかの状態になっています。
-
degraded – インスタンスは実行中であるか実行可能になっていますが、機能が制限されています。
-
disabled – インスタンスは有効でなく、実行中でも実行可能でもありません。
-
maintenance – インスタンスは有効になっていますが、実行できません。管理アクションがまだ完了していないためにインスタンスは maintenance 状態に遷移している可能性があります。それ以外の場合は、問題を解決するために管理アクションが必要です。
-
offline – インスタンスは有効になっていますが、実行中でも実行可能でもありません。たとえば、サービスが有効になっていてもその依存関係が満たされていない場合、そのサービスは offline 状態に保たれます。
-
online – インスタンスは有効になっており、実行中であるか実行可能になっています。online 状態は、正しく構成されたサービスインスタンスのすべての依存関係が満たされた場合に予想される動作状態です。
-
uninitialized – この状態はすべてのサービスの初期状態です。
サービスインスタンスは、管理アクションや依存サービスの状態などの条件に応じて、状態を遷移します。たとえば、disabled 状態のインスタンスを有効にすると、新しく有効になったインスタンスは、最初にoffline 状態になり、その依存関係がすべて充足されると online 状態に遷移します。
現在の状態に加えて、管理者は補助状態を表示できます。リスタータ (サービスリスタータを参照) は、補助状態を使用して、状態に関する情報を格納します。マスターリスタータは、補助状態を使用して、インスタンスが現在の状態に遷移した理由を格納します。たとえば、online 状態に遷移したあとの補助状態の値は通常 dependencies_satisfied です。Oracle Solaris 11.3 でのシステムサービスの開発 の 定期的なサービスの作成で説明されているように、定期的なリスタータは、補助状態を使用して、定期的なタスクが現在実行中であるかどうかを格納します。
これらのサービス状態と、サービスインスタンスがこれらの状態をどのように遷移するかについての詳細は、smf(5) のマニュアルページを参照してください。
サービス依存関係
サービスは、サービス、サービスインスタンス、またはファイルに対して依存関係を持つ場合があります。サービス依存関係はサービス間の関係を定義します。
依存関係によって、サービスが起動するタイミングや自動停止するタイミングが決まります。サービスが有効になっていてもその依存関係が充足されていない場合、そのサービスは offline 状態になっています。サービスが有効になっていてその依存関係が充足されている場合、そのサービスは起動します。サービスの起動が成功すると、そのサービスは online 状態に遷移します。
サービス依存関係は、サービスが状態を遷移すると再評価されます。サービス依存関係が充足されていても、あとから充足されなくなる場合があります。ファイル依存関係は一度だけ評価されます。
依存関係は必須の場合もオプションの場合もあります。サービス依存関係は実行している必要がある場合も、無効になっている必要がある場合もあります。依存サービスは、そのサービス依存関係のいずれかが停止またはリフレッシュしたときに再起動するかどうかを構成できます。
依存関係では次の機能が可能です。
スケーラブルで再現可能な初期化プロセス
独立したサービスを並行して起動することによる、並行機能を持つシステム上でのシステムの起動の高速化
障害によって直接影響を受けるサービスだけを依存関係の正しい順序で再起動することによる、正確な障害隔離および障害回復
サービスリスタータ
各 SMF サービスインスタンスは、リスタータによって管理されます。リスタータは、インスタンス構成を取得し、実行環境を提供します。すべてのリスタータに共通した情報については、smf_restarter(5) を参照してください。
マスターリスタータデーモン
svc.startd デーモンは、SMF のマスターリスタータデーモンであり、すべてのサービスインスタンスのデフォルトリスタータです。svc.startd デーモンは、すべてのサービスインスタンスおよびその依存関係の状態を管理します。インスタンスがオンライン状態に移行したときに依存関係が充足されていると、マスターリスタータは、ほかのインスタンスの起動メソッドを呼び出すか、起動メソッドを呼び出すように委任リスタータに指示します。マスターリスタータは、インスタンスの依存関係が充足されなくなると、サービスインスタンスを停止します。リスタータは、インスタンスに障害が発生すると、インスタンスの再起動を試みます。インスタンスは、そのすべての依存関係が充足されるまでオンラインにできないので、インスタンスの依存関係が、インスタンスの再起動動作の判断に役立ちます。それぞれの依存関係宣言で設定されているプロパティーによって、その依存関係が必要かどうかと、どのような場合に依存関係が再起動したときにインスタンスを再起動するかが定義されます。
その他のタスクの中では、svc.startd デーモンが、適切な /etc/rc*.d スクリプトを適切な実行レベルで起動します。これは以前に init で行われていた作業です。
次の例では、svc.startd が network/ipmp:default サービスインスタンスのリスタータであることを示します。ほかの出力は、この例から省略されています。
$ svcs -l ipmp:default restarter svc:/system/svc/restarter:default
restarter プロパティーが空または svc:/system/svc/restarter:default に設定されている場合、サービスインスタンスは svc.startd によって管理されます。svc.startd デーモンの詳細は、svc.startd(1M) のマニュアルページを参照してください。
委任リスタータ
一部のサービスは、起動時に共通の動きが見られます。委任リスタータは、これらのサービスに特定の実行環境とアプリケーション固有の再起動動作を提供します。restarter プロパティーで指定された委任リスタータが利用可能になると、このリスタータがサービスインスタンスの管理を担います。
Oracle Solaris には次の委任リスタータが含まれています。
- inetd
-
inetd 委任リスタータは、インターネットサービスを常に実行しておくのではなく、要求に応じてサービスを起動できます。inetd リスタータは、入力および出力ファイル記述子として、ネットワーク接続から構成される環境をそのサービスインスタンスに提供します。inetd デーモンの詳細は、inetd(1M) のマニュアルページを参照してください。次の例では、inetd が cups/in-lpd:default サービスインスタンスのリスタータであることを示します。ほかの出力は、この例から省略されています。
$ svcs -l cups/in-lpd:default restarter svc:/network/inetd:default
- svc.periodicd
-
定期的なリスタータデーモン svc.periodicd は、システムの起動時に svc:/system/svc/periodic-restarter サービスの一部として自動的に呼び出され、何らかの障害が発生した場合は自動的に再起動されます。定期的なリスタータによって起動されたサービスは、永続的にオンラインのままになりますが、その起動メソッドタスクを定期的またはスケジュールされた時間にのみ実行します。定期的なサービスの起動メソッドタスクは、比較的短い期間実行されたあとで終了することになっています。定期的なリスタータの詳細は、svc.periodicd(1M) のマニュアルページを参照してください。定期的なサービスの詳細は、Oracle Solaris 11.3 でのシステムサービスの開発 の 第 3 章, 定期的に実行するサービスの作成を参照してください。
サービスプロパティーおよびプロパティーグループ
依存関係、メソッド、状態、アプリケーションデータなどサービスに関する情報は、一連のプロパティーとしてサービス構成リポジトリに格納されます。プロパティーは、サービスまたはサービスのインスタンスのどちらかに対して定義できます。サービスに対して設定されるプロパティーは、そのサービスのすべてのインスタンスに継承されます。インスタンスに対して設定されたプロパティーは、そのインスタンスだけで使用されます。サービスインスタンスは、継承したプロパティーの値をカスタマイズでき、親サービスに対して定義されていない追加プロパティーを定義できます。
プロパティーはプロパティーグループにまとめられます。一般的なプロパティーグループには次のものがあります。
-
general – インスタンスが有効かどうかなどの情報を格納します。
-
restarter – インスタンスの現在の状態など、サービスのリスタータによって保存される実行時情報を格納します。
-
start、refresh、stop – サービスを起動、リフレッシュ、または停止するためにどのプログラムを実行するかなどの情報を格納します。
-
config – アプリケーションデータを保持するためにサービス開発者が使用します。
プロパティーとプロパティーグループの詳細は、smf(5) のマニュアルページを参照してください。
サービス構成リポジトリ
各サービスの情報は、サービス構成リポジトリに格納されており、このリポジトリは SMF データベースとも呼ばれます。サービス構成リポジトリには、サービス、インスタンス、プロパティーグループ、およびプロパティーとして情報が格納されます。サービス構成リポジトリには、サービス開発者によって定義された情報に加えて、システムでの各サービスインスタンスの起動時間や現在の状態などの情報が格納されます。
リポジトリには、永続的な構成情報と、サービスの SMF 実行時データが格納されます。
-
永続的な構成情報は、データのソースに応じてレイヤーに格納されます。リポジトリレイヤーを参照してください。
-
実行時データ、つまり非永続的な構成情報は、リブートすると保持されず、リポジトリには、非永続データのレイヤー情報は格納されません。非永続データは通常、アクティブなプログラム状態を保持します。
リポジトリには、タイプ、値の制約、プロパティーの説明などのサービステンプレートデータも格納されます。テンプレートデータはサービスマニフェストで定義されます。テンプレートデータの詳細は、smf_template(5) のマニュアルページを参照してください。
サービス構成リポジトリは、SMF インタフェースを使ってのみ操作または照会できます。svcs、svcprop、svcadm、および svccfg のコマンドを使用するか、libscf(3LIB) のマニュアルページに一覧表示されたサービス構成機能ライブラリの関数を使用します。プロパティー値は読み書きでき、指定したレイヤーおよびスナップショットにプロパティー値を表示できます。レイヤーの詳細は、リポジトリレイヤーを参照してください。スナップショットの詳細は、リポジトリのスナップショットを参照してください。選択したサービスインスタンスまたは親サービスのプロパティーだけを表示することも、プロパティーの合成ビューを表示することもできます。合成ビューでは、親サービスに対して設定されたプロパティーとサービスインスタンスに対して設定されたプロパティーの両方が表示されます。表示される値はサービスインスタンスに対して設定された値です。
サービスバンドル
サービスバンドルとは、サービスまたはサービスインスタンスのサービス構成リポジトリに格納されている情報を格納した XML ファイルです。サービスバンドルで提供される情報は、サービス構成リポジトリに格納され、リポジトリからエクスポートできます。標準の場所におけるサービスバンドルは、システムブート中にリポジトリにインポートされます。
サービスバンドルには、マニフェストとプロファイルの 2 つのタイプがあります。
- マニフェスト
-
マニフェストには、特定のサービス群またはサービスインスタンス群に関連付けられたプロパティーがすべて含まれます。
- プロファイル
-
プロファイルは通常、マニフェストで提供される情報を追加したりオーバーライドしてカスタマイズしたサービスまたはサービスインスタンスを提供します。カスタマイズの例としては、プロパティーの追加やプロパティー値の変更があります。
マニフェストの標準の場所は /lib/svc/manifest です。プロファイルの標準の場所は /etc/svc/profile です。
システムがブートするか、マニフェストインポートサービスが再起動すると、マニフェストがインポートされ、プロファイルが新規作成または変更されていれば、これが適用されます。サービスバンドルを提供する IPS パッケージは、パッケージをインストールするときにマニフェストインポートサービスを再起動するように指定できます。
ローカルカスタマイズは、/etc/svc/profile/site ディレクトリ内の接尾辞が .xml のプロファイルファイルで提供できます。同じリポジトリレイヤー内で同じサービスまたはインスタンスに対して同じプロパティーが複数のマニフェストまたはプロファイルによって定義されている場合、SMF は使用する値を判断できません。このような競合が検出された場合、インスタンスは maintenance 状態に置かれます。レイヤーの詳細は、リポジトリレイヤーを参照してください。
Oracle Solaris にサービスを提供する以外に、サービスバンドルは、さまざまなシステムに対してカスタム構成を提供することもできます。
システムプロファイル /etc/svc/profile/generic.xml はインストール中に適用されます。このプロファイルは変更しないでください。このシステムプロファイルに行われた変更はアップグレードで上書きされます。詳細は、smf_bootstrap(5) のマニュアルページを参照してください。
リポジトリレイヤー
サービス構成リポジトリには、単一のプロパティーに対して異なる値を格納できます。リポジトリは、データのソースに応じて、レイヤーにデータを格納します。ソースとしては、マニフェスト、システムプロファイル、サイトプロファイル、および、SMF のコマンドおよびライブラリインタフェースで行われたカスタマイズがあります。さまざまなレイヤー内の値を表示して、実行中の構成における値のソース、つまりその値がマニフェストまたはプロファイルで割り当てられたものか、管理者により変更されたものかを判断できます。値が設定されているレイヤーの表示を参照してください。
SMF コマンドおよびライブラリインタフェースを使用して行われた構成変更は、admin レイヤーにのみ表示されます。ほかのレイヤーでの構成は、標準の場所にあるプロファイルおよびマニフェストファイルで定義されます。ファイルからリポジトリーにプロパティーを追加したり、ファイル内のプロパティー値を変更したりしたとき、svccfg listprop コマンドの -f または -o file オプションを使用することによって、その構成を提供したファイルの名前を表示できます。構成に関係したファイルの表示を参照してください。
プロパティーが異なるレイヤーに異なる値を割り当てた場合、サービスインスタンスによって使用される値は、レイヤー階層内の最上位レイヤーの値になります。次の表は、階層内のレイヤーの順序を示したものです。たとえば、site-profile レイヤーにプロパティーの値があるとき、その値は manifest レイヤーまたは下位レイヤーの値をオーバーライドします。admin レイヤーにプロパティーの値があるとき、その値はほかのあらゆるレイヤーに設定されているほかのすべての値をオーバーライドします。
|
構成の競合はどのレイヤーでも許可されていません。SMF コマンド、sysconfig コマンド、または SMF ライブラリインタフェースを使用して設定された構成は、以前の設定を上書きします。ある単一レイヤー内の複数のファイルで構成が競合し、その構成が上位のレイヤーでは設定されていない場合、manifest-import サービスログにはこの競合が記され、競合している構成を使用したサービスは開始されません。詳細は、競合する構成を参照してください。
構成データのレイヤーを指定して、管理カスタマイズであるデータや、ソフトウェアで提供されたデータを表示し、したがって特定することができます。構成データの取得元のレイヤーが SMF クライアントによって指定されない場合は、最上位のレイヤーデータが与えられます。最上位のレイヤーは上の表に示す順序で決定され、admin レイヤーが最上位レイヤーで、manifest レイヤーが優先順位がもっとも低いレイヤーです。admin レイヤーにプロパティーの値がある場合、これがリポジトリで提供する値になります。ローカルカスタマイズは、このようにして、システムがインストールされたときに与えられた値よりも優先されます。
リポジトリのスナップショット
リポジトリは、サービスが正しく起動するごとに、読み取り専用のスナップショットを取得します。これらのスナップショットを使用すれば、必要に応じて簡単に以前の作業状態に戻せます。次のスナップショットはどのインスタンスでも使用できます。
- initial
-
サービスとそのインスタンスが最初にインポートされたときの初期構成。マニフェストのインポート前にプロファイルがサービスまたはインスタンスを起動した場合、initial スナップショットは作成されません。
- previous
-
すでに提供されているサービスに対してマニフェストのインポートが実行されたときに取得された現在の構成。このサービスは、インポートされているマニフェストまたは別のマニフェストによって、すでに提供されている可能性があります。
- running
-
サービスインスタンスの実行中の構成。構成データを変更する場合、svcadm refresh コマンドまたは svccfg refresh コマンドを使用して、新しい値を実行中のスナップショットにプロモートします。
- start
-
online 状態への正常な遷移中に取得された構成。
リポジトリのバックアップ
SMF は、サービス構成リポジトリの次のバックアップを自動的に作成します。
-
boot バックアップは、システムを起動するたびに、リポジトリに対する最初の変更が行われる直前に行われます。
-
サービスが新しいマニフェストをインポートしたか、アップグレードスクリプトを実行した場合、manifest_import のバックアップは、svc:/system/early-manifest-import:default または svc:/system/manifest-import:default が完了する前に行われます。
タイプごとに 4 つのバックアップがシステムで保守され、必要に応じてもっとも古いバックアップから削除されます。
これらのいずれかのバックアップからリポジトリを復元できます。バックアップからリポジトリを復元する方法を参照してください。