PIDの再考1.パート4

Upstartについて

まず、Upstartコードが非常に好きであり、非常によく文書化されており、ナビゲートしやすいことを強調しておきます。 一般に、他のプロジェクト（私のものを含む）は彼の例から学ぶべきです。



私はこれを言いましたが、Upstartで使用されているアプローチに概ね同意するとは言えません。 しかし、初心者向けには、Upstartについてもう少し説明します。



Upstartはsysvinitとコードを共有せず、その機能はアドオンであり、よく知られているSysVスクリプトとある程度の互換性を提供します。 その主な機能はイベント指向のアプローチです。プロセスの開始と停止はシステム内のイベントに結び付けられ、ネットワークインターフェースのアクセシビリティやプログラムの起動など、さまざまなことがイベントとして機能します。



Upstartは、これらのイベントを通じてサービスをシリアル化します。syslogで開始された信号が送信された場合、D-Busを開始するための信号として使用され、Syslogが使用できるようにします。 さらに、 dbus-started信号が送信されると、NetworkManagerが起動されます。これは、D-Busなどを使用できるようになったためです。



このようにして、管理者が存在し理解している現在の実際の依存関係は、一連のイベントと動作ルールに単純に変換およびエンコードされたと言うかもしれません：管理者/開発者が心配する各論理ルール「 a needs b 」は、「実行a when bは開始し、「 bが停止したらaを停止」します。 状況によっては、これは単純に物事を単純化したものです。Upstart自体のコードの場合です。 それでも、この単純化は実際には有害であると私は主張します。 まず、論理的な依存関係は消えません。Upstartファイルを作成する人は、これらの論理的な依存関係を一連のイベントと動作ルールに手動で変換するように強制されます（実際、各依存関係には2つのルールがあります）。 その結果、依存関係に基づいて何をすべきかをマシンに把握させる代わりに、ユーザーは依存関係をイベント/動作のルールの単純なセットに手動で変換する必要があります。 また、依存関係情報は決してエンコードされないため、実行時に利用できません。つまり、これがなぜ発生したのか、たとえばbが開始されたときに開始された理由を見つけようとしている管理者彼は見つける機会がありません。



さらに、イベントのシステムはすべての依存関係を逆さまにします。 作業量を最小限に抑える代わりに（記事の冒頭で述べたように、適切なローディングシステムが行うべきです）、実際に行う必要がある作業量を増やします。 または、言い換えると、明確な目標を持ち、目標を達成するために本当に必要なことだけを行うのではなく、彼は一歩を踏み出し、このステップを完了した後、彼に続く可能性のあるすべてのステップを実行します。



簡単に言えば、ユーザーがD-Busを起動したという事実は、NetworkManagerを起動する必要があることを示すものではありません（ただし、これはUpstartが実際に行うことです）。 反対の場合、このステートメントも真です。ユーザーがNetworkManagerを要求すると、これは明らかにD-Busを起動する必要があることを示します（ほとんどのユーザーはこれを見ると思いますよね？）。



適切なブートシステムは、必要なものだけをオンデマンドで実行する必要があります。 そして、「遅延」ロードを使用するか、事前に並行処理を使用します。 それでも、必要以上に起動するべきではありません。特に、インストールされていてサービスを使用できるすべてのものを起動する必要はありません。



最後に、イベントロジックを使用することの本当の利点はありません。 Upstartに表示されるイベントのほとんどは実際には時間どおりではなく、ある程度のランタイム（サービスの開始、実行、停止）があるように思えます。 デバイスが接続され、使用可能になり、再び切断されます。 接続プロセス中のマウントポイントは、完全に接続および切断されます。 電源ケーブルが接続され、システムの電源がオンになり、電源ケーブルが切断されます。 ブートシステムまたはプロセス、オブザーバーは、時間厳守に対応するためにイベントの最小数を制御する必要があります。そのほとんどは、開始、条件、および停止のシーケンスです。 繰り返しになりますが、この情報は単一のイベントに焦点を当て、ランタイム依存関係を無視するため、Upstartでは使用できません。



今、私は何らかの形で上で述べた問題のいくつかが、Upstartの最新の変更、特に、Upstartルールファイルのstart on（local-filesystem and net-device-up IFACE = lo）などの条件に基づく構文によって解決されたことを認識していますああ。 しかし、私にとってこれは、コードに重大な欠陥があるシステムを修正する試みのように思えます。



これらすべてを残して、Upstartは、一部のソリューションが曖昧に見えても（上記参照）、多くの未実現機能（上記も参照）がある場合でも、サービスの優れた「看護師」です。



Upstart、sysvinit、launchd以外のブートシステムがあります。 それらのほとんどは、Upstartまたはsysvinitをほとんど提供しません。 最も興味深いライバルは、サービス間の正しい依存関係を維持するSolaris SMFです。 ただし、多くの場合、それらは複雑すぎて、XMLの使い過ぎや、よく知られているものの新しい用語について少し学問的に言ってみましょう。 また、 契約システムなどの特定のSolaris機能と密接に関連しています。

すべてをまとめる

ですから、良いPID 1がどのように振る舞うべきか、そして現在のほとんどのシステムが何をすべきかを説明し、犬が埋葬されている場所を見つける前に、今が2番目の休憩の良い時期です。 だから、新しいコーヒーを注いでください。 それは価値があります。



おそらく、理想的なブートシステムの要件と機能として上記で提案したものが、 systemdと呼ばれる（これまでの実験的な）ブートシステムで実際に利用できるようになったと思います。 そして再び、 ここにコードがあります。 そして、その機能とその背後にある合理性の粒の簡単な概要です。



systemdは、システム全体を実行および管理します（名前に注意してください...）。 上記の機能全体と、さらにいくつかを実装します。 すべてはユニットの概念に基づいています。 ユニットにはタイプと名前があります。 ユニットは通常、ファイルシステムから構成をダウンロードするため、ユニット名はファイル名です。 例： avahi.serviceユニットは、同じ名前の設定ファイルを読み取ります。もちろん、Avahiデーモンをカプセル化するユニットでもあります。 ユニットにはいくつかのタイプがあります。

1. サービス：これは最も明白なタイプのユニットです：起動、停止、過負荷、再初期化が可能なデーモン。 SysVとの互換性のために、独自の構成ファイルをサポートするだけでなく、古典的なSysVブートスクリプトを読み取る機能も備えています。特に、LSBヘッダーが存在する場合は解析します。 したがって、/ etc / init.dは 、構成ファイルの別のソースにすぎません
2. ソケット：このユニットタイプは、ファイルシステムまたはインターネット上のソケットをカプセル化します。
   
   現時点では、ストリーミング、データグラム、シリアルパケットのタイプのAF_INET 、 AF_INET6 、 AF_UNIXソケットをサポートしています。 車両などの従来のFIFOもサポートしています。 各ソケットユニットには、対応するサービスユニットがあり、ソケットまたはFIFOへの最初の接続が受信されるとすぐに開始されます。 例： nscd.socketは、着信接続でnscd.serviceを開始します。
3. デバイス：このユニットタイプは、Linuxシステム上のデバイスをカプセル化します。 デバイスがudevルールでマークされている場合、systemdのデバイスユニットに表示されます。 udevを使用して設定されたプロパティは、 デバイスユニットの依存関係を確立するための構成ソースとして使用できます。
4. マウント：このユニットタイプは、ファイルシステム上のマウントポイントをカプセル化します。 systemdは、すべてのマウントポイントがライフパス上でさらに接続されている間監視し、マウントポイントの接続と切断にも使用できます。 / etc / fstabは、SysVブートスクリプトをサービスタイプのユニットの追加構成ソースとして使用できるように、マウントポイントの追加ソースとして使用されます 。
5. automount：このユニットタイプは、ファイルシステムの自動マウントポイントをカプセル化します。 各自動マウントユニットには、自動接続フォルダへのアクセスが試行されるとすぐに開始（接続）する対応するマウントユニットがあります。
6. ターゲット：このタイプのユニットは、ユニットを論理的にグループ化するために使用されます。実際に何か便利なことをする代わりに、単に他のユニットを参照し、その結果、それらを一緒に制御できます。 たとえば、従来のSysVシステムでランレベル5の役割を果たすmulti-user.target 、またはbluetoothドングルがシステムに接続されるとすぐに要求されるbluetooth.targetであり、単にすべてのbluetooth関連サービスを開始しますそれ以外の場合は実行されません：例としてbluetoothdとobexd
7. スナップショット：このタイプのユニットはターゲットに似ており、本質的には何も行いません。その唯一の目的は他のユニットを参照することです。 スナップショットを使用して、ブートシステムのすべてのサービスとユニットの状態を保存/ロールバックできます。 主に2つのケースで使用することを目的としています。ユーザーが一時的に「緊急シェル」などの特定の状態に移行できるようにすることです。 現在のサービスの中断と前の状態に戻る簡単な方法、すなわち 一時的に停止されたすべてのサービスを開始します。 また、システムを一時停止する簡単な方法として使用することもできます（スリープ）：システムがスリープモードになると正しく動作しないサービスが多くあり、多くの場合、スリープする前にこれらのサービスを停止し、終了後にスリープモードからシステムを開始することをお勧めします。

これらすべてのユニットは、相互に依存関係を持つことができます（正と負の両方、つまり「要件」と「競合」）。デバイスは、デバイスが利用可能になるとすぐに対応するサービスが開始されることに留意して、サービスに依存する場合があります。 マウントポイントは、接続されているデバイスに暗黙的に依存しています。 マウントポイントには、それらを移植する他のマウントポイントへの暗黙的な依存関係もあります（たとえば、マウントポイント/ home / lennartには暗黙的にマウントポイント/ homeがあります ）など。



機能の短いリストは次のとおりです。

1. 生成されるプロセスごとに、環境、リソース制限、作業ディレクトリとルートディレクトリ、umask、キラーOOM設定、ナイスレベル、IOクラスと優先度、CPUポリシーと優先度、CPUへのアトラクション、ユーザーID、グループID、サイドグループのID、読み取り/書き込みフォルダーと非アクセスフォルダー、一般/プライベート/セカンダリマウントフラグ、オプション/制限のセット、セキュリティ属性、CPUスケジューラー設定、プライベート/ tmpスペース、さまざまなサブシステムのcgroup。 また、stdin / stdout / stderrサービスをsyslog、/ dev / kmsg、または任意のTTYに簡単に接続できます。 入力のためにTTYに接続されている場合、systemdは、プロセスがTTYへの排他的アクセス権を持っていることを確認します。アクセスを待機するか強制します。
2. 実行中の各プロセスは独自のcgroupを取得します（デバッグサブシステムは他の目的に使用されず、単にプロセスをグループ化するだけなので、現在はデバッグサブシステムでのみ）。systemdの設定は非常に簡単です。 libcgroupsユーティリティを使用してみましょう。
3. 構成ファイルは、よく知られている.desktopファイルに厳密に従う構文を使用します。 これは単純な構文であり、多くのライブラリに存在するパーサーです。 また、サービスの説明でi18nの既存のツールを参照することもできます。 管理者と開発者は、新しい構文を学ぶ必要はありません。
4. 前述のとおり、SysVダウンロードスクリプトとの互換性を維持しています。 LSBおよびRed Hatのchkconfigヘッダーがあればそれを利用します。 それらが提示されていない場合、/ etc / rc.dの起動優先順位など、利用可能な情報から最適なものを絞り込もうとします。 SysVブートスクリプトは追加の構成ソースとして使用されるため、systemdへの移行パスが簡素化されます。 オプションで、サービスのクラシックPIDファイルを読み取って、マスターサービスプロセスを特定できます。 LSBヘッダーを取得し、それらをsystemd依存関係システムに変換することに注意してください。 注意散漫：Upstartはこの種の情報を収集して使用することはできません。 LSB SysVスクリプトが優先されるシステムでUpstartを使用してダウンロードすると、systemdと同じシステム上にありますが、並列化されません。 実際、Upstartの場合、すべてのSysVブートスクリプトは1つのタスクとして一緒に実行されますが、systemdの場合は別の構成ソースであり、すべてネイティブのsystemdサービスとして個別に管理および指定されます。
5. 同様に、既存の/ etc / fsta bを読み取り、追加の構成ソースと見なします。 fstabオプションcomment =を使用して、/ etc / fstabの要素をsystemd制御のマウントポイントとしてマークすることもできます。
6. 同じユニットが複数の構成ソースで構成されている場合（たとえば、ファイル/etc/systemd/system/avahi.serviceおよび/etc/init.d/avahiがある場合 ）、ネイティブ構成ファイルが優先され、古い構成ファイルは無視され、パッケージが許可されますSysVスクリプトとsystemd構成ファイルの両方をしばらく使用します。
7. シンプルなテンプレート/インスタンスメカニズムをサポートしています。 たとえば、6つのgettyの 6つの構成ファイルをサポートする代わりに、 getty @ tty2.serviceなどに対して作成されるgetty @ .serviceインスタンスを1つサポートするだけです。 インターフェース部分は、依存関係式、つまり dhcpd@eth0.serviceサービスがavahi-autopid@eth0.serviceを開始することは簡単にエンコードできます
   
   文字列の一部-eth0-をマスクしたままにします。
8. ソケットをアクティブ化するために、従来のinetdモードとの完全な互換性と、launchdのアクティブ化方法をシミュレートする非常にシンプルなモードをサポートしています。これは新しいサービスに推奨される方法です。 Inetdモードでは、デーモンに1つのソケットのみを転送できますが、ネイティブサポートモードでは、必要な数のファイル記述子を転送できます。 接続ごとに1つのインスタンスだけでなく、接続ごとに1つのインスタンスもサポートします。 最初のモードでは、接続パラメーターを使用して、起動されるサービスのcgroupを呼び出し、上記のテンプレートロジックを使用します。 例： sshd.socketは、cgroup sshd @ .service / 192.168.0.1-4711-192.168.0.2-22と呼ばれるsshd@192.168.0.1-4711-192.168.0.2-22サービスを生成できます（つまり、IPアドレスとポート番号インスタンス名に使用されます。AF_UNIXソケットの場合、PIDとクライアント接続識別子を使用します。 このようなメカニズムにより、管理者はサービスのさまざまなインスタンスを識別したり、ランタイムを個別に制御したりすることができます。 ネイティブソケット転送モードは、アプリケーションに非常に簡単に実装できます。 $ LISTEN_FDS変数が設定されている場合、転送されたソケットの数が含まれ、デーモンはハンドル3から始まる.serviceファイルで示されているようにソートされたソケットを見つけることができます（よく書かれたデーモンはfstat（ getsocketname（）は、複数のソケットが送信される場合に各ソケットを識別するために使用します）。 さらに、環境変数は通常、子プロセスに継承されるため、 $ LISTEN_PID変数をファイル記述子が受け取るデーモンのPID値に設定します。 さらに、このようなソケット転送ロジックは、デーモンに非常に簡単に実装できます。 これを使用する方法を示すライセンス付きのリファレンス実装をBSDに提供します。 このスキームを実装するいくつかのデーモンを移植しました。
9. ある程度、 / dev / initctlとの互換性を提供します。 実際、この互換性は、これらの古いリクエストをD-Busリクエストに単純に変換するFIFOアクティブ化サービスで実現されます。 基本的に、これは、Upstartおよびsysvinitからの古いshutdown 、 poweroff、および同様のコマンドがsystemdで引き続き機能することを意味します。
10. また、 utmpとwtmpの互換性も提供します。 おそらく、既存のutmpおよびwtmpよりもわずかに優れたバージョンです。
11. systemdは、ユニット間のいくつかのタイプの依存関係をサポートします。 After / Beforeを使用して、ユニットのアクティブ化順序を妨げることができます。 また、完全に直交するRequiresおよびWantsは 、必須または必須ではない、積極的に要求される依存関係で表されます。 また、 Conflictsがあり 、これは否定的に必要な依存関係に変換されます。 最後に、使用頻度の低い依存関係のタイプも3つあります。
12. systemdには最小限のトランザクションシステムがあります。 つまり、ユニットが開始または停止する場合は、サービスとそのすべての依存関係を一時トランザクションに追加します。 次に、トランザクションが完了していることを確認します（つまり、すべてのユニットのAfter / Beforeをソートすることは循環的な性質を持たない）。 そうでない場合は、修正して、トランザクションから不要なジョブを削除してください。これにより、再帰が削除される可能性があります。 また、systemdは、サービスを起動することができる重要でないジョブを保留しようとしています。 必須ではないクエリとは、直接関係していないが、 Wantsなどの依存関係を介して取得されるクエリです。 最後に、既にキューに追加されているジョブと矛盾するジョブがあるかどうかを確認します。これにより、トランザクションが中断される可能性があります。 すべてのバズとトランザクションに一貫性があり（統合）、その影響が最小化されている場合、今後のタスクとマージされ、起動キューに追加されます。 実際には、これは、要求された操作を実行する前に、実行する意味があるかどうかを確認し、可能な場合は修正し、実際に解決できない状況が発生した場合は「降伏」することを意味します。
13. 開始/停止時間、および開始および監視する各プロセスのPIDおよび終了コードを記録します。 このデータを使用して、abrtd、audited、syslogのサービスとそのデータを相互接続できます。 デーモンのクラッシュを強調表示し、syslog、abrtd、およびauditdの適切なユーザーインターフェイスへの簡単なナビゲーションを提供するユーザーインターフェイスを想像してください。現在の起動時にこのデーモンに対して生成された情報が表示されます。
14. 私たちは、いつでもダウンロードプロセスの再実行をサポートしています。 デーモンの状態は、再実行前にシリアライズされ、実行後にデシリアライズされます。 このようにして、ブートシステムの更新を容易にし、ブートデーモンを最終デーモンに転送する簡単な方法を提供します。 autofsのオープンソケットとマウントポイントは、常にシリアル接続できるように正しくシリアル化されているため、クライアントはブートシステムが再起動することに気付かないことさえあります。 また、サービスの状態のほとんどが仮想FS cgroupでエンコードされているという事実により、シリアル化されたデータにアクセスせずに実行を継続することはできません。 再起動コードパスは、実際にはブートシステムの構成再ロードコードパスと非常によく似ており、再実行（実行頻度は低い）が構成の再ロード（おそらくより頻繁に開始される）としてもテストされます。
15. ブートシステムからブートスクリプトを削除し始め、Cで基本的なシステムセットアップの一部を書き留めて、systemdに直接転送しました。 これには、ファイルシステムAPI（ / proc 、 / sys 、 / devなどの仮想ファイルシステム）の接続とホスト名の設定も含まれます。
16. サーバーの状態は、D-Busを介して監視および監視されます。 まだ完成していませんが、はるかに進んでいます。
17. 今のところ、ソケットベースとバスベースのアクティベーションを強調したいので、ソケットとサービス間の依存関係をサポートします。 また、これらのタイプのサービスが準備完了を知らせる方法をいくつかサポートしています：フォークして開始プロセスを停止するステータス（つまり、 daemonize（）の従来の動作）を設定し、設定されたサービス名が表示されるまでバスを監視します。
18. systemdによってプロセスが生成されるたびに確認を求める対話モードがあります。 カーネル起動引数でsystemd.confirm_spawn = 1を渡すことで有効にできます。
19. カーネルパラメーターsystemd.default =を使用すると、systemdブートを開始するユニットを指定できます。 通常、 multi-user.targetのようなものを指定しますが、ターゲットの代わりに単一のサービスを指定することもできます。 箱からの例として、 非常に有用なinit = / bin / bashに類似したemergency.serviceを提供しますが、ブートシステムを実行する利点があるため、緊急シェルから完全なシステムをブートする機能を提供します。
20. また、サービスを開始/停止/検査できる最小限のユーザーインターフェイスもあります。 完全なユーザーインターフェイスにはほど遠いですが、デバッグツールとしては便利です。 Vala（uu eeee !!）で書かれており、 systemadmという名前が付いています。

systemdは多くの特定のLinux機能を使用し、POSIXに限定されないことを言わなければなりません。 これにより、他のオペレーティングシステムに転送するように設計されたシステムが提供できない巨大な機能にアクセスできます。



継続するには...