smf - サービス管理機能
Oracle Solaris サービス管理機能は、「サービス」と呼ばれる永続的に実行されるアプリケーションを提供するためのプログラミングモデルを定義します。また、この機能は、サービスを実行するためのインフラストラクチャーも提供します。サービスは、実行中のアプリケーション、デバイスのソフトウェア状態、その他の一連のサービスのいずれかを表現できます。このフレームワーク内では、サービスは「サービスインスタンス」オブジェクトとして表現されます。これは、サービスオブジェクトの子になります。インスタンスオブジェクトは、親であるサービスオブジェクトの構成を継承またはオーバーライドできます。これにより、複数のサービスインスタンス間で構成情報を共有することができます。すべてのサービスオブジェクトとインスタンスオブジェクトは、一連の構成情報を表現した単一の「スコープ」内に格納されます。ローカル Oracle Solaris インスタンスの構成は「localhost」スコープと呼ばれ、現在サポートされている唯一のスコープとなります。
各サービスインスタンスの名前は、障害管理リソース識別子 (Fault Management Resource Identifier、FMRI) に基づいて、スキーム「svc:」を使って付けられます。たとえば、システム起動時に起動される syslogd(8) デーモンは、次の名前が付けられたデフォルトのサービスインスタンスです。
svc://localhost/system/system-log:default svc:/system/system-log:default system/system-log:default
多くのコマンドでは FMRI の省略形も使用できます。そのような例については、svcs (1) のマニュアルページを参照してください。
上記の例では、default がインスタンスの名前、system/system-log がサービス名です。サービス名は、スラッシュ (/) で区切られた複数のコンポーネントから構成される場合があります。最後のものを除くすべてのコンポーネントで、そのサービスの「カテゴリ」が構成されます。サイト固有のサービスに名前を付ける場合は、site で始まるカテゴリを使用するようにしてください。
サービスインスタンスは、有効化または無効化されます。svcadm(8) コマンドを使用して、すべてのサービスを有効または無効にできます。
システム上の管理対象サービスインスタンスを一覧表示するには、svcs(1) コマンドを使用します。
管理者が標準の場所にあるマニフェストまたはプロファイルに基づくエンティティーを削除すると、そのエンティティーはマスクされて、SMF への通常のクエリーで表示されなくなります。マスクされたエンティティーを見つけるには svccfg listcust を使用し、削除するには svccfg の delcust サブコマンドを使用します。詳細は、svccfg(8) のマニュアルページを参照してください。
インスタンス名は英数字で始める必要がありますが、英数字以外に下線 (_)、ハイフン (-)、およびドット (.) も使用できます。名前の最初と最後の文字の間にコンマ (,) を 1 つ指定できます。例:
ORCL, rcapd com.oracle, rcapd
サービス名では、それぞれがインスタンス名と同じ制限下にある複数レベルの識別子をスラッシュ (/) で区切ることができます。たとえば、system/svc/restarter のようになります。
ASCII 文字のみを使用できます。
サービスインスタンスは、サービス、インスタンス、ファイルなどの一連の entities (エンティティー) に対する依存関係を持つ可能性があります。依存関係により、サービスがいつ起動され、いつ自動的に停止されるかが左右されます。サービスが有効化されていてもその依存関係が満たされていない場合、そのサービスはオフライン状態に保たれます。その依存関係が満たされると、そのサービスは起動されます。起動が成功すると、そのサービスはオンライン状態に移行します。サービスやインスタンスとは異なり、ファイルの依存関係は、ファイルが作成または削除されるたびに動的に評価されるということはありません。これらは 1 回だけ評価されます。
依存関係が満たされるかどうかは、サービスの grouping (グループ化) によって決まります。
引用されているすべてのサービスが実行中 (オンライン、機能低下のいずれか) の場合、または指定されているすべてのファイルが存在している場合に満たされます。
引用されているサービスのいずれかが実行中 (オンライン、機能低下のいずれか) の場合、または指定されているファイルの少なくとも 1 つが存在している場合に満たされます。
引用されているサービスが実行中 (オンライン、機能低下のいずれか) の場合、または管理アクションが行われないためにそれらのサービスが実行されていない場合 (つまり、管理アクションが行われないために起動されない依存関係に対して待機状態にあるために、それらのサービスが無効、保守、存在しない、またはオフライン状態になっている場合) に満たされます。不完全なサービスも、オプションの依存関係を満たします。
引用されているサービスが存在する場合に、起動順序を定義します。通常、引用されているサービスが存在し、有効になっているが、まだ実行されていない場合、依存関係は満たされません。引用されているサービスがオンライン、機能低下、無効、または保守状態にあるか、あるいは存在しないか不完全な状態にある場合に満たされます。また、依存関係が存在しないか、無効または保守状態にある満たされない依存関係のために、引用されているサービスがオフラインになっている場合にも満たされます。この依存関係タイプをファイルの依存関係に使用することはお勧めしませんが、使用した場合は require_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(8) で一覧表示でき、svccfg(8) で変更できます。
各サービスは特定のリスタータによって管理されます。マスターリスタータ svc.startd(8) は、一連のサービスインスタンス全体とそれらの依存関係の状態を管理します。マスターリスタータは、自身のサービスに代って各種処理を行うほか、特定アプリケーションクラス向けの特定実行環境を提供できる委任リスタータを制御します。たとえば、inetd(8) は、そのサービスインスタンスに、ネットワーク接続から構成される初期環境を入力および出力ファイル記述子として提供する委任リスタータです。inetd(8) に委任された各インスタンスはオンライン状態にあります。ある特定のインスタンスのデーモンが実行されていなくても、そのインスタンスを実行することは可能です。
インスタンスがオンライン状態に移行すると依存関係が満たされるため、svc.startd(8) はほかのインスタンスの起動メソッドを呼び出すか、または委任リスタータにそれを行うよう指示します。これらの処理はオーバーラップする可能性があります。
現在のサービス群およびそれらに関連付けられたリスタータを確認するには、svcs(1) を使用します。すべてのリスタータが使用する共通の構成については、smf_restarter(7) を参照してください。
各サービスまたはサービスインスタンスは、サービスの起動、停止、およびリフレッシュ (オプション) を行う一連のメソッドを定義する必要があります。svc.startd(8) および同様の fork(2)-exec(2) リスタータのためのメソッド規約の詳細は、smf_method(7) を参照してください。
レガシー構成情報をリポジトリに取得するためなどに使用する管理メソッドについては、svccfg(8) のマニュアルページで説明されています。
サービスのためのメソッドは、svccfg(8) コマンドを使用して一覧表示および変更できます。
各サービスインスタンスは常に明確に定義された特定の状態にありますが、どの状態になるかは、その依存関係、メソッドの実行結果、および契約イベントの可能性によって決まります。定義されている状態は、次のとおりです。
This state is the initial state for all service instances, including newly created instances (through executing svccfg add, importing a manifest, or applying a profile).When an instance is cleared from the maintenance state (svcadm clear), it is placed in the uninitialized state so that its restarter can re-evaluate its configuration.Instances are moved to maintenance, offline, or disabled state after evaluation by the appropriate restarter.Note that evaluation of an instance can only occur if its restarter service is online.
The instance is not completely installed on the system and has not been evaluated by its restarter.The instance is mentioned solely in a profile (and not explicitly marked complete in the profile), or is mentioned only as a dependent of another service.
インスタンスは有効になっていますが、まだ実行中でも実行可能でもありません。リスタータがあるサービスの起動メソッドまたはそれと同等のメソッドを正常に実行できた場合、そのインスタンスはオンライン状態に移行します。失敗した場合は通常、機能低下、保守のいずれかの状態に移行することがあります。管理アクションを行うと未初期化状態に移行する可能性があります。
インスタンスは有効になっており、実行中であるか実行可能になっています。オンライン状態の具体的な内容はアプリケーションモデルに固有であり、サービスインスタンスを管理するリスタータによって定義されます。オンラインは、適切に構成されたサービスのすべての依存関係が満たされた場合に予想される動作状態です。インスタンスで障害が発生すると、機能低下、保守のいずれかの状態に移行する可能性があります。インスタンスが依存するサービスで障害が発生すると、オフライン、機能低下のいずれかの状態に移行する可能性があります。
通常の動作と比較すると、インスタンスはある制限された機能レベルで動作しています。インスタンスで障害が発生すると、保守状態に移行する可能性があります。インスタンスが依存するサービスで障害が発生すると、オフライン、機能低下のいずれかの状態に移行する可能性があります。インスタンスメソッドで障害が発生すると、機能低下状態に移行する可能性もあります。機能が回復すると、オンライン状態に移行します。
インスタンスを開始、停止、または継続実行できません。インスタンスを保守状態から移行させるには、修正ステップ実行後の svcadm clear による管理アクションが必要です。インスタンスがクリアされると、SMF はインスタンスの状態を構成済みに遷移させます。インスタンスが無効になっている場合、SMF はインスタンスを無効状態に遷移させます。インスタンスが有効になっている場合、SMF はインスタンスをオンラインにしようとします。
インスタンスは無効になっています。サービスを有効化するとオフライン状態に移行し、最終的には、すべての依存関係が満たされた時点でオンライン状態に移行します。
この状態は、サービス管理機能によって管理されていないレガシーインスタンスを表します。この状態のインスタンスはある時点で起動されたものですが、それが実行中かどうかはわかりません。この機能を使って行えるのは、インスタンスの監視だけであり、ほかの状態に移行させることはできません。
状態の移行には、結果的に元の状態に戻るようなものもあります。
SMF では、SNMP または SMTP を使用することで状態の遷移を通知できます。これは、snmp-notify(8) や smtp-notify(8) などの通知デーモンによって消費される状態遷移に関する情報イベントを発行します。無効になっているサービスの SMF 状態遷移では、通知は生成されません。ただし、遷移の最終状態が「無効」で、その遷移に関する通知パラメータが存在する場合に限り、通知が生成されます。遷移の初期状態と最終状態が同じである場合、通知は生成されません。
SMF 状態遷移によって生成される情報イベントを除き、FMA イベントの通知パラメータは svc:/system/fm/notify-params:default に保存されます。これらは、サービスまたは遷移中のサービスのインスタンスに保存されます。SMF 状態遷移によって生成されるイベントの通知パラメータは、システム全体のパラメータとして svc:/system/svc/global:default で設定できます。システム全体の通知パラメータは、scf_instance_get_pg_composed (3SCF) と同様の合成検索が遷移中のインスタンスに見つからない場合に使用されます。通知パラメータは、svccfg(8) を使用して操作できます。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.* 階層に含まれる) の別名ですが、後者は通知の構成に使用しないようにしてください。
新しい問題が FMA サブシステムによって診断されました。診断には、1 つ以上の疑わしいリソースからなるリストが含まれています。これらのリソースは、それ以上のエラーの発生を防ぐために、自動的に隔離されている可能性があります (適切な場合)。問題はイベントペイロードの UUID で識別されます。この問題の解決ライフサイクルを表す追加のイベントには、一致する UUID が使用されます。
問題の診断に含まれていた疑わしいリソースの 1 つ以上が、修復または交換されたか、または疑いがなくなりました (あるいは、再度障害が発生しました)。ただし、障害の発生したリソースが少なくとも 1 つリストに残っています。修復は、fmadm コマンド行 (fmadm repaired、fmadm acquit、fmadm replaced) の結果であるか、または部品シリアル番号の変更の検出などによって自動的に検出された可能性があります。
問題の診断に含まれていた疑わしいリソースのすべてが、修復または解決されたか、または疑いがなくなりました。この段階では、一部またはすべてのリソースがまだ隔離されている可能性があります。
問題の診断に含まれていた疑わしいリソースのすべてが、修復または解決されたか、疑いがなくなりました。さらに、隔離も解除されました (オフライン状態にあった疑わしい CPU がオンラインに戻った場合など。通常、この隔離解除のアクションは自動的に行われます)。
状態遷移セットは次のように定義されます。
遷移の最終状態が <state> である、すべての遷移のセット。
遷移の初期状態が <state> である、すべての遷移のセット。
遷移の初期状態が <state> である、すべての遷移のセット。
すべての遷移のセット。
state の有効な値は、maintenance、offline、disabled、online、および degraded です。遷移セットの定義の例は、maintenance、 from-online、to-degraded などです。
これまでに説明した依存関係、メソッド、委任リスタータ、およびインスタンス状態は、サービスまたはサービスインスタンスのプロパティーまたはプロパティーグループとして表現されます。サービスまたはサービスインスタンスには、アプリケーションデータを格納するための任意の数のプロパティーグループがあり、それらのプロパティーグループをほかのプロパティーグループ要素内にネストして、複雑な階層アプリケーション構成データを表現できます。プロパティーグループをこのような方法で使用すれば、リポジトリがこの機能内のすべてのデータに対して提供する属性を、アプリケーションの構成情報から導き出すことができます。また、アプリケーションは、service_bundle(5) DTD の適切なサブセットを使ってフレームワーク内の自身の構成データを表現することもできます。
プロパティーの検索は合成されます。あるプロパティーグループとプロパティーの組み合わせがサービスインスタンス上で見つからなかった場合、libscf(3LIB) の大部分のコマンドや高レベルインタフェースは、その同じプロパティーとプロパティーグループの組み合わせを、そのインスタンスを含むサービス上で検索します。これにより、共通の構成をサービスインスタンス間で共有することが可能になります。この合成は、サービスインスタンスとその親であるサービスとの間の一種の継承関係として捉えることができます。
プロパティーは、承認されていないプロセスによる変更から保護されます。smf_security(7) を参照してください。
general プロパティーグループはすべてのサービスインスタンスに適用されます。次のプロパティーが含まれています。
インスタンスが有効になっているかどうかを指定します。このプロパティーがインスタンス上に存在しない場合、SMF は、そのインスタンスのリスタータにインスタンスの存在について通知しません。
このサービスのリスタータ。詳細については、「リスタータ」のセクションを参照してください。このプロパティーが設定されていない場合は、システムのデフォルトのリスタータが使用されます。
このサービスが完了したか、または開始すべきでない部分的な定義であるかを示します。このプロパティーは、マニフェストのインポート時に自動的に設定されます。または、このプロパティーを持たないインスタンスがテンプレート定義に対して正常に検証されると (scf_tmpl_validate_fmri(3SCF) を参照)、有効になったときに svcadm(8) によってこのプロパティーが作成されます。
true に設定されている場合は、目標サービスの動作をアクティブ化します。詳細は、「目標サービス」のセクションを参照してください。
リポジトリは、管理カスタマイズ、現在の状態、および標準の場所にあるファイルからのデフォルト値の組み合わせで構成されています。SMF 管理のファイルシステムの位置にあるマニフェストによって定義されているサービス、インスタンス、プロパティーグループ、およびプロパティーは、リポジトリ内で常に正確に表現されます。管理者またはほかのプログラムによって実行時に行われたカスタマイズは、捕獲されてリポジトリに保管されます。
プロパティーはリポジトリ内で、マニフェスト、プロファイル、および管理カスタマイズからの異なる設定を反映した異なる値を持つ場合があります。デフォルトでユーザーおよびサービスに提供される値は、 レイヤーと呼ばれる単純な優先度スキームによって調停されます。
SMF によって 7 つのレイヤーが追跡されます。優先度の高い順に示すと、次のようになります。
SMF コマンドまたはライブラリの対話型使用によって実行されたすべての変更。このレイヤーは優先度がもっとも高くなります。
/etc/svc/profile/sysconfig ディレクトリ内のファイルのすべての値。このディレクトリは、Oracle Solaris インストーラおよび sysconfig によって排他的に使用されます。特定の sysconfig(8) 操作によって、このディレクトリのすべてのプロファイルが削除される可能性があります。
/etc/svc/profile/node ディレクトリ内のファイルまたは旧バージョンの /etc/svc/profile/site.xml ファイルのすべての値。これらのファイルは、Oracle Solaris の特定のインスタンスに固有の構成を表すことを目的にしています。
/etc/svc/profile/site ディレクトリ内のファイルのすべての値。これらのファイルは、共通の場所にある多数のシステムに共通の構成を表すことを目的にしています。
/etc/svc/profile/enterprise ディレクトリ内のファイルのすべての値。これらのファイルは、Oracle Solaris インスタンスの分散配置内のほとんどのシステムに共通の構成を表すことを目的にしています。
/etc/svc/profile/system ディレクトリとファイル /etc/svc/profile/generic.xml および /etc/svc/profile/platform.xml のすべての値。
システムマニフェストの場所 /lib/svc/manifest または /var/svc/manifest のすべての値。
個々のレイヤー内におけるプロパティーの競合は許可されません。admin レイヤーに競合するプロパティーがある場合、以前のプロパティーが単純に上書きされます。同じプロパティーがほかのいずれかのレイヤー内の複数のファイルによって配信され、かつ上位レイヤーで設定されていない場合は、インスタンス全体が競合状態としてタグ付けされ、競合中の定義が削除されるか、またはそのプロパティーが上位レイヤーで設定されるまで、svc.startd(8) によって起動されません。svccfg や svcprop など、1 つの値を要求しているその他の libscf コンシューマは、すべての適切な値の中からランダムなプロパティー設定を参照します。競合している値のどれが返されるかは保証されません。
enterprise-profile、site-profile、および node-profile レイヤーは、一般に役立つ設定を多数のシステムにわたって適用できるようにして、システムのグループや個々のシステムの容易なオーバーライドを可能にすることを目的にしています。たとえば、ある企業に通常はすべてのサーバーで使用される一連の DNS サービスがあるが、その企業は特定のサイトまたは個々のマシン用に特殊な設定を必要としている可能性があります。zoneadm(8) インストールを使用して、プロファイルをさまざまなレイヤーに選択的に配信できます。詳細は、solaris(7) および solaris-kz(7) のマニュアルページを参照してください。
リポジトリ内の各インスタンスに関する履歴データが、サービス管理機能によって管理されます。このデータは、管理上の検査やロールバック向けの読み取り専用スナップショットとして利用可能となります。利用可能なスナップショットタイプは次のとおりです。
管理者によって作成されたかパッケージインストール中に生成されたインスタンスの初期構成。
元に戻す管理操作を実行する際に取得された、その時点における構成。
インスタンスの実行中の構成。
オンライン状態への正常移行中に取得された構成。
svccfg(8) コマンドを使用すると、スナップショットを操作できます。
プロパティーグループの中には、「非永続的」とマークされているものがあります。それらのグループはスナップショット内にバックアップされず、その内容はシステムブート中にクリアされます。そのようなグループは一般に、システムの再起動時に消えてもかまわないようなアクティブプログラム状態を保持します。
各サービスインスタンスの現在の状態や、サービスおよびサービスインスタンスに関連付けられたプロパティーは、svc.configd(8) によって管理されるシステムリポジトリ内に格納されます。
サービス管理機能データのためのリポジトリは、svc.configd(8) によって管理されます。
構成リポジトリ内に格納されている、サービスまたはサービスインスタンスに関連付けられた情報は、XML ベースのファイルとしてエクスポートできます。サービスバンドルと呼ばれるそれらの XML ファイルは移植性に優れており、バックアップ用途に適しています。サービスバンドルは次のいずれかのタイプに分類されます。
特定のサービス群またはサービスインスタンス群に関連付けられたプロパティーをすべて含んだファイル。
一連のサービスインスタンスと各インスタンスの enabled プロパティー (general プロパティーグループの boolean 型プロパティー) の値を含んだファイル。
プロファイルには、サービスおよびインスタンスのプロパティーの構成値も含まれることがあります。プロファイルにテンプレート要素を定義することはできません。
プロファイルでは、service_bundle(5) で説明されている DTD の要素の緩和されたセットを使用できます。これらを使用するには、DOCTYPE エントリに次の定義を追加するようにしてください:
<!ENTITY % profile "INCLUDE"> <!ENTITY % manifest "IGNORE">
サービスバンドルは、svccfg(8) コマンドを使用して、リポジトリからインポートまたはエクスポートできます。サービスバンドルのファイル形式や作成時のガイドラインについては、service_bundle(5) を参照してください。
smf マイルストーンは、複数のサービス依存関係を集約するサービスです。通常、マイルストーンは、それ自体で有用な機能を果たすことはありませんが、ほかのサービスが利用できるようにシステム対応状況の特定の状態を宣言します。たとえば、name-services マイルストーンは、単に現在有効になっているネームサービスに依存します。
Oracle Solaris の既存のマイルストーン: none、config、devices、unconfig、network、single-user、name-services、self-assembly-complete、multi-user、および multi-user-server。
システム管理者は、目標サービスを使用することで、システムが起動し、その本来の目的で機能しているときに実行されているべき一連の期待されるサービスを定義できます。
目標サービスは、そのすべての依存関係が充足可能であるように期待されます。依存関係が満たされるために管理者の介入が必要な場合、目標サービスは保守状態に置かれます。保守状態にある目標サービスは、その依存関係が充足可能になると、その状態から自動的に抜けます。
通常、実際の作業を行うサービスには goal service 設定を使用するべきではありません。
動的に有効にされるサービスに依存する目標サービスを設定することはお勧めしません。動的に有効にされるサービスは、別のサービスで有効にされるまで、goal service を保守状態に入れます。管理者は、svcadm(8) サブコマンドの目標を使用して、目標サービスの依存関係を設定できます。
milestone/goalsmilestone/goals は、システムが起動して実行されていると判断できる、はっきりと明確に定義された地点を提供するための目標サービスです。milestone/goals の依存関係は、システムにとってミッションクリティカルなサービスを表すように構成する必要があります。milestone/goals のデフォルトの依存関係は次のとおりです。
svc:/milestone/multi-user-server:default
/etc/rc?.d ディレクトリ内の起動プログラムは、対応する実行レベルのマイルストーンの一部として実行されます。
milestone/single-user:default
milestone/multi-user:default
milestone/multi-user-server:default
各プログラムの実行は特定の機能限定版のサービスインスタンスとして表現され、プログラムのパスに基づいて命名されます。これらのインスタンスは、特殊な状態であるレガシー実行状態に保たれます。
これらのインスタンスは enabled プロパティー (general プロパティーグループ内の型 boolean) を持っていないため、一般に、svcadm(8) コマンドでは操作できません。これらのプログラムについては、エラー診断や再起動は行われません。
svcs(1), exec(2), fork(2), strftime(3C), libscf(3LIB), scf_tmpl_validate_fmri(3SCF), contract(5), service_bundle(5), smf_bootstrap(7), smf_method(7), smf_restarter(7), smf_security(7), inetd(8), smtp-notify(8), snmp-notify(8), svc.configd(8), svc.startd(8), svcadm(8), svccfg(8), solaris(7), solaris-kz(7), zoneadm(8)