サービス管理機能は、サービスマニフェストの配信、サービスマニフェストの変更の組み込み、サービス構成の安定性の記述、サービス構成の優先指定の使用、およびサービスプロファイルの使用に関する規約を定めます。
システムのブート時と、管理者またはプログラムが実行するときは常に、標準のディレクトリツリー /lib/svc/manifest および /var/svc/manifest からのマニフェストが処理されます。
$ svcadm restart manifest-import
以前インポートされなかったか、最後にインポートされてから変更されたマニフェストが処理されます。マニフェストが変更されたかどうかを判断するためにハッシュが使用されます。
標準の場所にあるマニフェストがはじめてインポートされると、マニフェストのプロパティー、インスタンス、およびサービスが、manifest レイヤーの一部としてリポジトリに追加されます。
標準の場所にあるマニフェストは、更新されると自動的にインポートされます。新しいサービスおよびインスタンスは追加され、変更されたプロパティーはアップグレードされ、削除されたサービス、インスタンス、およびプロパティーは削除されます。
マニフェストはブート中に 2 つの段階で処理されます。
サービス svc:/system/early-manifest-import:default は、最初のマニフェスト処理を担当する擬似サービスです。このサービスは /lib/svc/manifest ディレクトリツリーにあるマニフェストだけを処理します。この処理は、svc.startd(1M) がサービスを初期化する前に行われるため、/lib/svc/manifest で配信されているサービスは常に最新の定義で起動されます。これは擬似サービスなので svcadm(1M) コマンドは無視されます。ただし、svcs(1) を使用して、ステータスの監視とログファイル情報の取得を行うことはできます。
svc:/system/manifest-import:default サービスは 2 番目のマニフェスト処理を担当し、まず /lib/svc/manifest、次に /var/svc/manifest の順に、これら両方のディレクトリツリーからマニフェストファイルをインポートします。
/var/svc/manifest のサポートは、system/early-manifest-import:default の導入より前にそのディレクトリツリーで配信されていたマニフェストに対する互換性サポートです。/var/svc/manifest で配信されているサービスには、アップグレード関連の問題が発生する可能性があります。つまり、更新されたマニフェストがまだインポートされていないために、サービスが古いリポジトリ構成で起動する可能性があります。同様に、マニフェストファイルがまだ処理されていないために、新たに追加されたサービスが使用できなくなったり、削除されたサービスがブート中に起動したりすることもあります。このような問題を避けるために、開発者にはマニフェストを /lib/svc/manifest に移動することを強くお勧めします。
このセクションで説明している操作では、*.xml ファイルのみが考慮されます。
プロファイルは early-manifest-import サービスおよび manifest-import サービスによっても適用されます。
/etc/svc/profile/generic.xml および /etc/svc/profile/platform.xml にあるシステム配信プロファイルは system-profile レイヤーにインポートされます。
/etc/svc/profile/generic.xml にあるシステム配信プロファイルは system-profile レイヤーにインポートされます。
管理者は次を実行することによって、これらのプロファイルが再適用されることを要求できます。
$ svcadm restart manifest-import
プロファイルによって定義されるプロパティー、インスタンス、およびサービスの動作は、マニフェストによって定義される動作と同じです。
このセクションで説明している操作では、*.xml ファイルのみが考慮されます。
パッケージ内のサービスマニフェストは、クラス manifest によって識別されます。サービスマニフェストのインストールと削除を行うクラスアクションスクリプトは、パッケージ化サブシステムに含まれています。pkg install が呼び出されると、サービスマニフェストがインポートされます。
pkg uninstall が呼び出されると、無効になっているマニフェスト内のインスタンスが削除されます。マニフェスト内のインスタンスで、オンライン状態または機能低下状態になっているものは、まず無効化され、そのあとで削除されます。また、インスタンスが残っていないマニフェスト内のサービスもすべて削除されます。
マニフェストで配信する各サービスグループおよび各プロパティーグループには、attributes(5) の定義に基づく安定性レベルを宣言するようにしてください。アプリケーション開発者は、サービスやオブジェクトの存在またはそのコンポーネントを基に機能を開発する場合に、安定性レベルがわかっていれば、リリースが変わっても動作するかどうかを判断しやすくなります。
smf(5) のコンテキストでは、安定性の値は、そのサービスのリリースが変わるときに想定される、プロパティーグループ内のプロパティーに対する変更の範囲も示します。これにはそのサービスのパッチも含まれます。次の 2 つのセクションでは、これについて詳細に説明します。
service_bundle(4) ドキュメント型定義には、サービスマニフェスト内の各プロパティーグループに適用できる delete 属性があります。 true に設定されている場合、delete 属性は svccfg(1M) およびほかのマニフェストインポートツールに対し、このプロパティーグループをリポジトリから削除するように指示します。delete 属性が存在しないか false に設定されている場合、そのプロパティーグループはリポジトリに保持されます。
「安定」または「開発中」と宣言されているプロパティーグループは削除されません。「不安定」と宣言されているプロパティーグループは、リリースが変わるときに削除される可能性があります。
svcs (1) , svcadm (1M) , svccfg (1M) , svc.startd (1M) , libscf (3LIB) , service_bundle (4) , attributes (5) , smf (5) , smf_security (5) , pkg (1)
Packaging and Delivering Software With the Image Packaging System in Oracle Solaris 11.2
smf(5) の現在のバージョンでは、複数のリポジトリはサポートされていません。