web-dev-qa-db-ja.com

「init」と「service manager」の違いは何ですか？

From オペレーティングシステムがシャットダウンすると、サービスマネージャーはSIGTERMとSIGKILLをサービスに送信する必要があることをどのようにして知るのですか？

systemd IS initとservice managerの両方

「init」と「service manager」の違いは何ですか？

彼らは同じものだと思いますか？

「init」で「service manager」ではない例は何ですか？逆に？

ありがとう。

linuxsystemdservicesinitsysvinit
5
Tim

initは（通常）システムによって開始される最初のプロセスです。これには、次のような特別な責任がいくつかあります（ただし、これらに限定されません）。

  • 起動プロセスを完了するために必要な他のユーザースペースプロセスを開始する。
  • システムの最後のシャットダウンの処理（initは、ユーザースペースのすべてがシャットダウンされたら、最終的にカーネルに電源をオフにするか再起動するように指示するものです）。
  • 孤立したプロセス（親プロセスが実行されていないプロセス）を採用し、その後にクリーンアップします。

一方、サービスマネージャーは、特定のサービスセットが実行されていることを確認する責任を単独で負い、オプションでそれらのサービスが実行され続けることを保証します。これに対する正確なアプローチは、サービス間の依存関係を追跡するだけの基本的なスクリプトから、依存関係を自動的に管理する複雑なシステムまでさまざまです。

元のSVR4 init実装（ほとんどのLinuxディストリビューションの従来のsystemv-initパッケージ、Busybox initアプレット、およびBSDとSolarisのinitプログラムの両方の基礎）には、基本的なサービス管理が実際に含まれていました。起動時に自動的に起動するプログラムを定義し、プログラムが終了した場合に再起動します。その結果、UNIXライクなシステムで、基本的なサービスマネージャーではないinitの実装を見つけるのは実際にはかなり難しく、このベースラインレベルのサービス管理は、initプロセスのジョブの一部であることがほとんどです。

一方、init実装ではないサービスマネージャーを簡単に作成できます。古典的なBSD rc.dスクリプトは非常に単純なサービスマネージャー（サービスの開始と停止を処理し、基本的な依存関係管理を提供する）の例であり、Linuxでの/etc/init.dの概念の基礎を形成しました。より複雑な例はmonitで、これは状態追跡、自動再起動機能、アラート、および一部のシステム監視サポートを基本機能に追加します。

4
Austin Hemmelgarn

initは、プロセス＃1で実行されるプログラムの従来の名前です。それは何年にもわたって多くの形を取り、initプログラムが実行するタスクは大幅に変化しました。紛らわしいことに、これは、管理者がプロセス＃1との通信に使用するコマンドの名前でもあります。それらは2つの別個のものと見なされ、AT＆T Unixでは確実にそのように文書化されました。たとえソフトウェアによっては、1つのプログラムに混在していても、そのプロセスIDによって検出されるプロセスIDによって動作が異なる場合があります。さらに紛らわしいことに、システムの存続期間中にプロセス＃1によって実行される複数の異なるプログラムが存在する可能性があり、そのうちの少なくとも2つ（initramfsを備えたLinuxシステムの場合）はinit（/init initramfs内および/sbin/initは最終的にルートファイルシステム内にあり、従来は前者によってチェーンされていました）。

service managerは、名前が示すように、サービスを管理するプログラムです。これはプロセス＃1として実行する必要はなく、実際、長年にわたる幅広いオペレーティングシステムソフトウェアにわたって、一般的には実行されていませんプロセス＃1。サービスマネージャーの範囲は、Gerrit Papeの runsv からLaurent Bercotの s6-supervise から想像上の名前の service-manager までさまざまです。私のせいでまた、AT＆T Unix System 5 Release 4のサービスアクセス機能、IBM AIX 3.1のシステムリソースコントローラ、Solarisのサービス管理機能も含まれます。それらは、統一された一貫性のある既知のコンテキストからサービスプログラムを生成し、それらのサービスを制御（起動、終了、再起動、および削除）するためのメカニズムと、システムの残りの部分から照会されるステータスを提供します。

system managerは、システムの状態変化を処理するシステムを管理するプログラムです。通常、isプロセス＃1として実行されます。これは一部には、オペレーティングシステムのカーネルがそれを特別に扱い、停電イベントやカーネル仮想端末のキーボードデバイス上の特別なキーコード（Linuxなど）のようなシステム状態変更要求に関する情報を送信するためです ⇮+↑SIGWINCHまたは ⎈+⎇+⌦ ＃1を処理するためにSIGINTを生成します。また、ブートストラップ時の初期システム状態の設定、およびシャットダウン時のシステム状態の確定も扱います。

システム状態の詳細は、ソフトウェアによって異なります。 van Smoorenburg initは、（現在は古い）実行レベルで動作しました。 BSD initの状態マシンは完全に内部であり、running /etc/rc、multi-user、およびsingle user.

ケーススタディ：

  • systemdはプロセス＃1のプログラムです。サービス管理とシステム管理の両方を1つのプログラムで実行し、そのプロセスとして実行します。ただし、システム状態の確定は処理されません。代わりに、プロセス＃1を systemd-shutdown という名前の別のプログラムにチェーンロードします。システム状態の変化は、通常、サービスマネージャーの開始/停止targetsの形式をとります。これにより、services。 emergency.serviceやsystemd-halt.serviceなどのいくつかのサービスは、アクティブ化されるとsystemctlを実行し、コマンドをプロセス＃1に送り返して、システム状態をさらに変更します。この設計では、シャットダウンは2つの状態のシーケンスです。
  • 私のnosh toosetの想像上の名前が付けられた system-manager は、システムマネージャロールのみを実行するプロセス＃1プログラムです。 bootstrapでの初期化とシャットダウン時のファイナライズを行います。（システム全体の）サービスマネージャを別のプロセスとして生成することでシステムを管理しますおよびイベントへの応答としての system-control プログラムのさまざまな呼び出し（（SIGINT ⎈+⎇+⌦ KVTキーボードのコードにより、子プロセスが生成され、たとえばsystem-control start secure-attention-keyが実行されます。）system-controlは、サービスとターゲットを開始および停止するコマンドをサービスマネージャーに発行します。同様に、いくつかのサービス/ターゲットはsystem-controlを呼び出して、コマンドをsystemマネージャーに送り返すので、アクティブ化すると、システム状態の変更がさらに要求されます。サービスプロセスは、プロセス＃1の孫です。
  • runit は、システム管理のみを行うプロセス＃1プログラムです。他のプロセスとしてサービスマネージャを起動します。これは、runitの人々が「ステージ2」と呼ぶもので実行されます。次に、シェルスクリプトを呼び出して、チェーンロード runsvdir を実行し、いくつかのrunsvプログラムを次のように起動します。プロセス＃1の孫プロセス。サービスプロセスは、プロセス＃1のひ孫です。システム管理では、信号とフラグファイルの組み合わせによってトリガーされる「3つのシェルスクリプトを実行するだけ」のアプローチを採用しています。
  • システム5 initは、システム管理のみを行うプロセス＃1プログラムでした。システムの状態として前述の実行レベルがあり、理論上はサービスマネージャーでもかまいません。実際には、そのサービス管理機能は非常に機能が乏しいため、数年後にはTUIログインサービス管理にも使用されなくなりました。前述のSAFおよびSRCの形式で、（はるかに機能的な）サービスマネージャを子プロセスとして生成しました。

    1990年までに、使用中の実行レベルの数は1に減少し、実際の操作ではこれら数十年後のnosh system-managerとほぼ同じ設計が得られ、プロセス＃1は主にサービスマネージャーの子プロセスを生成し、さらにカーネルプロセスと管理者コマンドに応答してコマンドを実行する子プロセス。サービスプロセスは、プロセス＃1のひ孫であり、さまざまなサービスマネージャプロセスの孫と子です。 （たとえば、TUIログインサービスプロセスは、ttymonプロセスによって生成され、それ自体がsacプロセスから生成され、プロセス＃1によって生成されます。）

  • van Smoorenburg initは、System 3 initおよびSystem 5 initに似ています。Unixで前述のサービスマネージャーが登場する数年前のことです。これは、システムマネージャーの役​​割を実行し、一部のサービスも管理するプロセス＃1のプログラムです（同じ機能では不十分ですが、個々のサービスの開始/停止をシステム5として細かく制御できませんinit） 。サービス管理は、それが（サービスプログラムを単にオフにして大部分を忘れるのではなく）行われる場合、子プロセスの他のプログラムによって行われます。

    systemdとnoshツールセットのsystem-managerの両方とは対照的に、子プロセスで実行されているプログラムにいくつかのシステム管理アクションを残します。 systemdとsystem-managerの両方が、システムのpoweroff/restart/halt（カーネルへの適切なシステムコールを行う）の最終動作を（システム化されたケースでは別のプログラムではあるが）プロセス1で実行しますが、 van Smoorenburgシステムでは、これらはrcを介して呼び出される子プロセスで実行されます。例：システムの停止を制定する最後のシステムコールは、haltの子プロセスとして実行されるrcシェルスクリプトを介して実行されます（それ自体がプロセス＃1の子です） 次に、実際にシステムコールを行うhaltプログラム （プロセス＃1のひ孫として）を実行します。

参考文献

14
JdeBP

これは非常に良い質問であり、すぐに回答できる質問ではありません。私の答えは JdeBP を補完するものです。

「初期システム」について話すとき、私たちは実際には4つの異なることについて話しています。以下を参照してください。これは混乱を招くドメインです。関係する概念を分離するために時間をかけている人はほとんどいないため、用語に同意できない人もいます。 :-)

たとえば、Jonathanがservice managerと呼ぶものは、サービスではなくプロセスを管理するため、process supervision systemと呼んでいます。より正確には、抽象（「サービス」）を提供しますが、longrunサービス（つまり、デーモンを介して実装されるサービス）のみをカバーし、その抽象（プロセス）の実装を隠します。 、ユーザーがprocessesの代わりにservicesをアドレス指定できるようにします。

そして、ジョナサンがシステムマネージャと呼んでいるものは、サービスマネージャと呼んでいます。これは、サービスを開始および停止するツールであるため、間違いなくそれらを管理しますが、それはマシンのグローバルな状態を処理するツールであるため、「システムマネージャ」という用語も意味があります。私はmachine state managerを好みますが。とにかく、私たちは本当に混乱を減らすのに非常に役立つであろう条件について合意に達するべきです。

では、initシステムとは何でしょうか？それは本当に4つのことです：

  • マシンの起動時に実行される最初のプログラム。伝統的に、それは/sbin/initという名前であり、それがこのプログラムを扱うときに使用する用語です。
  • pid 1として実行される、マシンのほとんどの存続期間中、存続期間の長いプログラムです。これは、 /sbin/init、なぜなら/sbin/initは他のプログラムで実行される可能性があるためです。sysvinit、またはsystemdの場合、pid 1 is /sbin/init。s6ベースのシステムの場合、そうではありません。
  • プロセス監視システム。これは基本的に、デーモンが死んだときにデーモンを再起動するシステムであり、それに加えて、どんなpidであってもデーモンの現在の具体化に対処するツールです。 initシステムがこれを少なくとも1つのプロセスに対して持っている必要があります。持っていない場合、システム上のすべてのプロセス（savepid 1)が停止し、マシンが使用できなくなり、コンソールからの再起動が必要になります。
  • machine state manager（あいまいな用語を避けるため）。これは、マシンの状態を「すべてダウン」から「必要なすべてのサービスをアップ」にするソフトウェアであり、マシンの実行中に実行中のサービスのセットを変更し、シャットダウンをトリガーすることもできます。

これらは、initシステムの4つの重要な部分です。では、既存のinitシステムはどのように機能するのでしょうか。

  • sysvinitは/sbin/init、pid 1、非常に初歩的な監視システム（/etc/inittabの行を介して実装）を提供します）、およびmachine state managerはありません。 sysvinitを使用するディストリビューションは、通常、sysv-rc（シェルスクリプトの従来の束）またはOpenRCをmachine state managerとして使用します。
  • OpenRCはマシン状態マネージャーです。最近のバージョンでは、初歩的な監視システムも提供しています。しかし、それは/sbin/initまたはpid 1を提供しません：OpenRC自体はinitシステムではありません。
  • systemdは、4つの要素すべてを1つのプロセスで提供します。つまり、systemdは両方とも「初期化」です（つまり、/sbin/initまたはpid 1またはその両方）および「サービスマネージャー」、「サービスマネージャー」が監視システムまたはを意味するかどうかマシン状態マネージャー。
  • すべてのdaemontoolsのようなアプローチは本質的に監視システムです。 runit は/sbin/initおよびpid 1も提供します。 s6 はpid 1を提供しますが、/sbin/initは提供しませんが、 s6-linux-init パッケージは提供します/sbin/init。これらのアプローチはmachine state managerを提供しませんが、s6はそのようなマネージャーにフックを提供し、2つが記述されています： s6-rc および anopa 。
  • nosh は、4つの要素すべてを個別のプロセスで提供します。ジョナサンは私よりもずっと上手にそれについて話すことができるでしょう。 :-)
  • 他のinitシステム（busybox init、BSD init、launchd、Epochなどの他のアプローチなど）を見ると、このinitが提供する要素は何ですか？何が足りないの？

私はこの投稿で簡単に要約できることを説明する15分のビデオと、initシステムの仕組みの奥深くに潜むより大きなスライドのデッキを持っています。それはすべて FOSDEM 2017アーカイブ で入手できます。気軽に探索してみてください。これらに興味がある場合は、 supervision mailing-list で説明します。

楽しい、

8
Laurent Bercot