機能説明

smf

- サービス管理機能

Solaris サービス管理機能は、「サービス」と呼ばれる永続的に実行されるアプリケーションを提供するためのプログラミングモデルを定義します。また、この機能は、サービスを実行するためのインフラストラクチャーも提供します。サービスは、実行中のアプリケーション、デバイスのソフトウェア状態、その他の一連のサービスのいずれかを表現できます。このフレームワーク内では、サービスは「サービスインスタンス」オブジェクトとして表現されます。これは、サービスオブジェクトの子になります。インスタンスオブジェクトは、親であるサービスオブジェクトの構成を継承または上書きできます。これにより、複数のサービスインスタンス間で構成情報を共有することができます。すべてのサービスオブジェクトとインスタンスオブジェクトは、一連の構成情報を表現した単一の「スコープ」内に格納されます。ローカル Solaris インスタンスの構成は「localhost」スコープと呼ばれますが、これが現在サポートされている唯一のスコープとなります。

各サービスインスタンスの名前は、障害管理リソース識別子 (Fault Management Resource Identifier、FMRI) に基づいて、スキーマ「svc:」を使って付けられます。たとえば、システム起動時に起動される syslogd(1M) デーモンは、次のような名前を持つデフォルトサービスインスタンスです。

svc://localhost/system/system-log:default
svc:/system/system-log:default
system/system-log:default

多くのコマンドでは FMRI の省略形も使用できます。そのような例については、svcs(1) のマニュアルページを参照してください。

上の例では、「default」がインスタンス名、「system/system-log」がサービス名になります。サービス名は、スラッシュ (/) で区切られた複数のコンポーネントから構成される場合があります。最後のコンポーネントを除くすべてのコンポーネントは、そのサービスの「カテゴリ」を構成します。サイト固有のサービスの名前は、「site」で始まるカテゴリを使って付けることをお勧めします。

サービスインスタンスは、有効化または無効化されます。すべてのサービスは、svcadm(1M) コマンドを使って有効化または無効化できます。

システム上の管理対象サービスインスタンスを一覧表示するには、svcs(1) コマンドを使用します。

依存関係

サービスインスタンスは、サービス、インスタンス、ファイルなどの一連の entities (エンティティー) に対する依存関係を持つ可能性があります。依存関係により、サービスがいつ起動され、いつ自動的に停止されるかが左右されます。サービスが有効化されていてもその依存関係が満たされていない場合、そのサービスはオフライン状態に保たれます。その依存関係が満たされると、そのサービスは起動されます。起動が成功すると、そのサービスはオンライン状態に移行します。サービスやインスタンスとは異なり、ファイルの依存関係は、ファイルが作成または削除されるたびに動的に評価されるということはありません。これらは 1 回だけ評価されます。

依存関係が満たされるかどうかは、サービスの grouping (グループ化) によって決まります。

require_all: 引用されているすべてのサービスが実行中 (オンライン、機能低下のいずれか) の場合、または指定されているすべてのファイルが存在している場合に満たされます。
require_any: 引用されているサービスのいずれかが実行中 (オンライン、機能低下のいずれか) の場合、または指定されているファイルの少なくとも 1 つが存在している場合に満たされます。
optional_all: 引用されているサービスが実行中 (オンライン、機能低下のいずれか) の場合、または管理作業が行われないためにそれらのサービスが実行されていない場合 (つまり、管理作業が行われないために起動されない依存関係に対して待機状態にあるために、それらのサービスが無効、保守、存在しない、またはオフライン状態になっている場合) に満たされます。不完全なサービスも、オプションの依存関係を満たします。
exclude_all: 引用されているすべてのサービスが無効になっているか保守状態にある場合、または引用されているサービスまたはファイルが存在していない場合に満たされます。

require_all、require_any、optional_all のいずれかの依存関係から引用されている特定のサービスが、いったん実行中 (オンライン、機能低下のいずれか) になったあとで停止または更新された場合、SMF は、そのサービスが停止した理由とその依存関係の restart_on 属性に基づいて、サービスを停止するかどうかを決定します。

                   |  restart_on value
event              |  none  error restart refresh
-------------------+------------------------------
stop due to error  |  no    yes   yes     yes
non-error stop     |  no    no    yes     yes
refresh            |  no    no    no      yes

あるサービスがエラーによって停止したとみなされるのは、コアダンプなどのハードウェアエラーやソフトウェアエラーがそのサービスで発生した場合です。exclude_all 依存関係の場合、引用されているサービスが起動され、かつ restart_on 属性が none 以外になっている場合にサービスが停止されます。

特定のサービスの依存関係を一覧表示するには svcs(1) または svccfg(1M) を使用し、変更するには svccfg(1M) を使用します。

リスタータ

各サービスは特定のリスタータによって管理されます。マスターリスタータ svc.startd(1M) は、一連のサービスインスタンスとその依存関係の状態をすべて管理します。マスターリスタータは、自身のサービスに代って各種処理を行うほか、特定アプリケーションクラス向けの特定実行環境を提供できる委任リスタータを制御します。たとえば、inetd(1M) は委任リスタータであり、入力ファイル記述子と出力ファイル記述子で表されるネットワーク接続から成る初期環境を、自身のサービスインスタンスに対して提供します。inetd(1M) に委任された各インスタンスは、オンライン状態になっています。ある特定のインスタンスのデーモンが実行されていなくても、そのインスタンスを実行することは可能です。

依存関係が満たされるには、各インスタンスがオンライン状態に移行する必要があります。このため、svc.startd(1M) は、ほかのインスタンスの起動メソッドを呼び出すか、委任リスタータにそうするように指示します。これらの処理はオーバーラップする可能性があります。

現在のサービス群およびそれらに関連付けられたリスタータを確認するには、svcs(1) を使用します。すべてのリスタータが使用する共通の構成については、smf_restarter(5) を参照してください。

メソッド

各サービスまたはサービスインスタンスは、サービスの起動、停止、および更新 (省略可能) を行う一連のメソッドを定義する必要があります。svc.startd(1M) および類似の fork(2)-exec(2) リスタータ用のメソッド規約の詳細については、smf_method(5) を参照してください。

レガシー構成情報を取得してリポジトリ内に格納するメソッドなど、各種の管理メソッドについては、svccfg(1M) のマニュアルページを参照してください。

特定のサービスのメソッドを一覧表示したり変更したりするには、svccfg(1M) コマンドを使用します。

状態

各サービスインスタンスは常に明確に定義された特定の状態にありますが、どの状態になるかは、その依存関係、メソッドの実行結果、および契約イベントの可能性によって決まります。定義されている状態は、次のとおりです。

未初期化: これは、すべてのサービスインスタンスの初期状態です。インスタンスは、svc.startd(1M) または適切なリスタータによって評価された結果、保守、オフライン、無効のいずれかの状態に移行します。
OFFLINE: インスタンスは有効になっていますが、まだ実行中でも実行可能でもありません。リスタータがあるサービスの起動メソッドまたはそれと同等のメソッドを正常に実行できた場合、そのインスタンスはオンライン状態に移行します。失敗した場合は通常、機能低下、保守のいずれかの状態に移行することがあります。管理作業を行うと未初期化状態に移行する可能性があります。
ONLINE: インスタンスは有効になっており、実行中であるか実行可能になっています。オンライン状態の具体的な内容はアプリケーションモデルに固有であり、サービスインスタンスを管理するリスタータによって定義されます。オンラインは、適切に構成されたサービスのすべての依存関係が満たされた場合に予想される動作状態です。インスタンスで障害が発生すると、機能低下、保守のいずれかの状態に移行する可能性があります。インスタンスが依存するサービスで障害が発生すると、オフライン、機能低下のいずれかの状態に移行する可能性があります。
DEGRADED: インスタンスは有効になっており、実行中であるか実行可能になっています。ただし、通常の動作と比較すると、インスタンスはある制限された機能レベルで動作しています。インスタンスで障害が発生すると、保守状態に移行する可能性があります。インスタンスが依存するサービスで障害が発生すると、オフライン、機能低下のいずれかの状態に移行する可能性があります。機能が回復すると、オンライン状態に移行します。
保守: インスタンスは有効になっていますが、実行可能ではありません。インスタンスを保守状態から移行させるには、svcadm clear による管理作業が必要です。何らかの管理操作を実施中の場合、この保守状態に一時的に達する場合があります。
無効: インスタンスは無効になっています。サービスを有効化するとオフライン状態に移行し、最終的には、すべての依存関係が満たされた時点でオンライン状態に移行します。
レガシー実行: この状態は、サービス管理機能によって管理されていないレガシーインスタンスを表します。この状態のインスタンスはある時点で起動されたものですが、それが実行中かどうかはわかりません。この機能を使って行えるのは、インスタンスの監視だけであり、ほかの状態に移行させることはできません。

状態の移行には、結果的に元の状態に戻るようなものもあります。

イベント通知

SMF では、SNMP または SMTP を使用することで状態の遷移を通知できます。状態遷移に関する情報イベントが発行され、snmp-notify(1M) や smtp-notify(1M) などの通知デーモンによって処理されます。無効になっているサービスの SMF 状態遷移では、通知は生成されません。ただし、遷移の最終状態が「無効」で、その遷移に関する通知パラメータが存在する場合に限り、通知が生成されます。遷移の初期状態と最終状態が同じである場合、通知は生成されません。

通知パラメータ

SMF 状態遷移によって生成される情報イベントを除き、FMA イベントの通知パラメータは svc:/system/fm/notify-params:default に保存されます。これらは、サービスまたは遷移中のサービスのインスタンスに保存されます。SMF 状態遷移によって生成されるイベントの通知パラメータは、システム全体のパラメータとして svc:/system/svc/global:default で設定できます。システム全体の通知パラメータは、scf_instance_get_pg_composed(3SCF) と同様の合成検索が遷移中のインスタンスに見つからない場合に使用されます。通知パラメータは svccfg(1M) を使用すると操作できます。DTD に記述されている notification_parameters 要素を使用すると、サービスマニフェストまたはサービスプロファイルで通知パラメータを構成できます。次に例を示します。

<notification_parameters>
     <event  value='from-online' />
     <type name='smtp' active="false">
        <parameter name='to'>
            <value_node value='root@local' />
            <value_node value='admin-alias@eng' />
        </parameter>
     </type>
     <type name='snmp' />
</notification_parameters>

events は、SMF 状態遷移セットをコンマで区切ったリストか、または FMA イベントクラスをコンマで区切ったリストです。events に SMF 状態遷移セットと FMA イベントクラスを混在させることはできません。

FMA サブシステムで診断される問題のライフサイクルを、初期の診断から暫定的な更新、最後の問題解決まで、problem- {diagnosed,updated,repaired,resolved} の各タグを利用して記述できます。これらのタグは、基になる FMA プロトコルイベントクラス (すべて list.* 階層に含まれる) の別名ですが、後者は通知の構成に使用しないようにしてください。

problem-diagnosed: 新しい問題が FMA サブシステムによって診断されました。診断には、1 つ以上の疑わしいリソースからなるリストが含まれています。これらのリソースは、それ以上のエラーの発生を防ぐために、自動的に隔離されている可能性があります (適切な場合)。問題はイベントペイロードの UUID で識別されます。この問題の解決ライフサイクルを表す追加のイベントには、一致する UUID が使用されます。
problem-updated: 問題の診断に含まれていた疑わしいリソースの 1 つ以上が、修復または交換されたか、または疑いがなくなりました (あるいは、再度障害が発生しました)。ただし、障害の発生したリソースが少なくとも 1 つリストに残っています。修復は、fmadm コマンド行 (fmadm repaired、fmadm acquit、fmadm replaced) の結果として、あるいは部品シリアル番号の変更の検出などを通して自動的に検出された可能性があります。
problem-repaired: 問題の診断に含まれていた疑わしいリソースのすべてが、修復または解決されたか、または疑いがなくなりました。この段階では、一部またはすべてのリソースがまだ隔離されている可能性があります。
problem-resolved: 問題の診断に含まれていた疑わしいリソースのすべてが、修復または解決されたか、疑いがなくなりました。さらに、隔離も解除されました (オフラインになっていた疑わしい CPU がオンラインに戻った場合など。通常、この隔離解除の処理は自動的に行われます)。

状態遷移セットは次のように定義されます。

to-<state>: 遷移の最終状態が <state> である、すべての遷移のセット。
from-<state>: 遷移の初期状態が <state> である、すべての遷移のセット。
<state>: 遷移の初期状態が <state> である、すべての遷移のセット。
all: すべての遷移のセット。

state の有効な値は、maintenance、offline、disabled、online、および degraded です。遷移セットの定義の例は、maintenance、 from-online、to-degraded などです。

プロパティーとプロパティーグループ

これまでに説明した依存関係、メソッド、委任リスタータ、およびインスタンス状態は、サービスまたはサービスインスタンスのプロパティーまたはプロパティーグループとして表現されます。サービスまたはサービスインスタンスは、任意の数のプロパティーグループを、アプリケーションデータの格納先として持つことができます。プロパティーグループをこのような方法で使用すれば、リポジトリがこの機能内のすべてのデータに対して提供する属性を、アプリケーションの構成情報から導き出すことができます。また、アプリケーションは、service_bundle(4) DTD の適切なサブセットを使ってフレームワーク内の自身の構成データを表現することもできます。

プロパティーの検索は合成されます。あるプロパティーグループとプロパティーの組み合わせがサービスインスタンス上で見つからなかった場合、libscf(3LIB) の大部分のコマンドや高レベルインタフェースは、その同じプロパティーとプロパティーグループの組み合わせを、そのインスタントを含むサービス上で検索します。これにより、共通の構成をサービスインスタンス間で共有することが可能になります。この合成は、サービスインスタンスとその親であるサービスとの間の一種の継承関係として捉えることができます。

プロパティーは、承認されていないプロセスによる変更から保護されます。smf_security(5) を参照してください。

general プロパティーグループ

general プロパティーグループはすべてのサービスインスタンスに適用されます。次のプロパティーが含まれています。

enabled (boolean): インスタンスが有効になっているかどうかを指定します。インスタンスにこのプロパティーが存在しない場合、SMF はインスタンスのリスタータにリスタータの存在を通知しません。
restarter (fmri): このサービスのリスタータ。詳細については、「リスタータ」の節を参照してください。このプロパティーが設定されていない場合は、システムのデフォルトのリスタータが使用されます。
complete (astring): このサービスが完了したか、または開始すべきでない部分的な定義であるかを示します。このプロパティーは、マニフェストのインポート時、または管理者がインスタンスを手動で作成するときに自動的に設定されるため、変更は不要なはずです。

レイヤー

リポジトリは、管理カスタマイズ、現在の状態、および標準の場所にあるファイルからのデフォルト値の組み合わせで構成されています。SMF 管理のファイルシステムの位置にあるマニフェストによって定義されているサービス、インスタンス、プロパティーグループ、およびプロパティーは、リポジトリ内で常に正確に表現されます。管理者またはほかのプログラムによって実行時に行われたカスタマイズは、捕獲されてリポジトリに保管されます。

プロパティーはリポジトリ内で、マニフェスト、プロファイル、および管理カスタマイズからの異なる設定を反映した異なる値を持つ場合があります。デフォルトでユーザーおよびサービスに提供される値は、 レイヤーと呼ばれる単純な優先順位スキームによって調停されます。

SMF によって 4 つのレイヤーが追跡されます。優先順位の高い順に示すと、次のようになります。

admin: SMF コマンドまたはライブラリの対話型使用によって実行されたすべての変更。このレイヤーは優先順位がもっとも高くなります。
site-profile: /etc/svc/profile/site ディレクトリのファイルか、レガシーの /etc/svc/profile/site.xml および /var/svc/profile/site.xml ファイルのすべての値。
system-profile: システムプロファイルの場所 /etc/svc/profile/generic.xml および /etc/svc/profile/platform.xml のすべての値
manifest: システムマニフェストの場所 /lib/svc/manifest または /var/svc/manifest のすべての値。

個々のレイヤー内におけるプロパティーの競合は許可されません。admin レイヤーに競合するプロパティーがある場合、以前のプロパティーが単純に上書きされます。同じプロパティーが複数のファイルによってほかのレイヤーで配信され、高いレイヤーで設定されない場合、インスタンス全体に競合状態のタグが付けられ、競合中の定義が削除されるか高いレイヤーでプロパティーが設定されるまでは、svc.startd(1M) によって開始されません。svccfg および svcprop などの単一の値を要求するその他の libscf 利用者は、すべての適切な値からランダムなプロパティー設定を取得します。競合中のどの値が返されるかは保証されません。

スナップショット

リポジトリ内の各インスタンスに関する履歴データが、サービス管理機能によって管理されます。このデータは、管理上の検査やロールバック向けの読み取り専用スナップショットとして利用可能となります。利用可能なスナップショットタイプは次のとおりです。

initial: 管理者によって作成されたかパッケージインストール中に生成されたインスタンスの初期構成。
previous: 元に戻す管理操作を実行する際に取得された、その時点における構成。
running: インスタンスの実行中の構成。
start: オンライン状態への正常移行中に取得された構成。

svccfg(1M) コマンドを使用すれば、スナップショットを操作できます。

特殊なプロパティーグループ

プロパティーグループの中には、「非永続的」とマークされているものがあります。それらのグループはスナップショット内にバックアップされず、その内容はシステムブート中にクリアされます。そのようなグループは一般に、システムの再起動時に消えてもかまわないようなアクティブプログラム状態を保持します。

構成リポジトリ

サービスやサービスインスタンスに関連付けられたプロパティーに加え、各サービスインスタンスの現在の状態が、svc.configd(1M) が管理するシステムリポジトリ内に格納されます。

サービス管理機能データ用のリポジトリを管理するには、svc.configd(1M) を使用します。

サービスバンドル、マニフェスト、およびプロファイル

構成リポジトリ内に格納されている、サービスまたはサービスインスタンスに関連付けられた情報は、XML ベースのファイルとしてエクスポートできます。サービスバンドルと呼ばれるそれらの XML ファイルは移植性に優れており、バックアップ用途に適しています。サービスバンドルは次のいずれかのタイプに分類されます。

manifests

特定のサービス群またはサービスインスタンス群に関連付けられたプロパティーをすべて含んだファイル。

profiles

一連のサービスインスタンスと各インスタンスの enabled プロパティー (general プロパティーグループの boolean 型プロパティー) の値を含んだファイル。

プロファイルには、サービスおよびインスタンスのプロパティーの構成値も含まれることがあります。プロファイルにテンプレート要素を定義することはできません。

プロファイルでは、service_bundle(4) で説明されている DTD の要素の緩和されたセットを使用できます。これらを使用するには、DOCTYPE エントリに次の定義を追加するようにしてください。

<!ENTITY % profile "INCLUDE">
<!ENTITY % manifest "IGNORE">

特定のリポジトリに対してサービスバンドルのインポート、エクスポートを行うには、svccfg(1M) コマンドを使用します。サービスバンドルのファイル形式や作成時のガイドラインについては、service_bundle(4) を参照してください。

マイルストーン

smf マイルストーンは、複数のサービス依存関係を集約するサービスです。通常、マイルストーンは、それ自体で有用な機能を果たすことはありませんが、ほかのサービスが利用できるようにシステム対応状況の特定の状態を宣言します。たとえば、name-services マイルストーンは、単に現在有効になっているネームサービスに依存します。

レガシー起動スクリプト

/etc/rc?.d ディレクトリ内の起動プログラムは、対応する実行レベルのマイルストーンの一部として実行されます。

/etc/rcS.d: milestone/single-user:default
/etc/rc2.d: milestone/multi-user:default
/etc/rc3.d: milestone/multi-user-server:default

各プログラムの実行は特定の機能限定版のサービスインスタンスとして表現され、プログラムのパスに基づいて命名されます。これらのインスタンスは、特殊な状態であるレガシー実行状態に保たれます。

これらのインスタンスは enabled プロパティー (general プロパティーグループの boolean 型プロパティー) を持たず、一般に svcadm(1M) コマンドを使って操作することもできません。これらのプログラムについては、エラー診断や再起動は行われません。

ナビゲーションリンクをスキップ
印刷ビューの終了
	マニュアルページセクション 5: 標準、環境、マクロ Oracle Solaris 11 Information Library (日本語)

smf