ウェブサイト検索

「Ubuntu Linux」システムの深い洞察 - これはわかりますか?


LINUX は、ご存知のとおり、オペレーティング システムではなくカーネルであり、DebianFedoraUbuntu などのいくつかのディストリビューションが同梱されています。strong>など、その他にもたくさんあります。 マーク・ シャトルワースによって開発された Ubuntu OS は広く知られており、多くの人に広く使用されています。また、無料でオープンソースであるため、その開発に貢献する何千人もの開発者の貢献により、新しいバージョンが毎年リリースされます。しかし、それはどのように機能するのでしょうか?すべてのプロセス、イベントのリストによって機能しますか?また、これらのプロセスの重要性は何ですか?

この記事では、非常に興味深いUbuntu OS の内部について少し詳しく説明し、初心者がその機能を完全に理解するのに役立ちます。

システムの設置

Linux には機能するためのプロセスがあり、電源管理、起動、システム クラッシュ処理を含むすべてのシステム サービスは、「/etc/init 」に設定ファイルがあり、そのイベントが記述されています。実行するイベントと、その実行を停止する対応するイベントを記録します。また、実行時の動作を記述する他の設定ファイルもシステムの「/etc/ 」ディレクトリに保持します。これにより、システムがイベント駆動型のもの。

イベントが生成された場合、それをキャッチして実行するために誰かがそこにいる必要がありますか??明らかに、コントローラーはプロセス ID 1 、つまり init を持つすべてのプロセスの親として存在するメイン プロセスです。これは、システムの起動時に開始され、決して停止しないプロセスです。 init の親であるプロセスが存在しないため、このプロセスはシステムの電源がオフになった場合にのみ終了します。

6.10 より前の Ubuntu の初期バージョンには、「/etc/rcx.d」でスクリプトを実行するために使用される古いスタイルの sysvinit が含まれていました。 b> 」ディレクトリは、システムの起動時とシャットダウンごとに実行されます。しかし、 その後、新興システムが古いスタイルのsysvinit システムを置き換えましたが、依然として下位互換性を提供しています。

最新の Ubuntu バージョンにはこの upstart システムが搭載されていますが、Ubuntu 6.10 からの進化以来、いくつかの改訂が行われ、2014 年 9 月 4 日現在のバージョンは 1.13.2 です。最新の upstart システム2 つの init プロセスがあり、1 つはシステム プロセスで、もう 1 つは現在ログインしているユーザー セッションを管理し、ユーザーがログインするまでのみ存在します。x-session init とも呼ばれます。 。

システム全体は、システムの電源投入から電源切断までの祖先と子の関係からなる階層構造として構築されています。

: 両方の init プロセス間の小さな階層関係は次のとおりです: system init(1) -> Display Manager(kernel space) ->ディスプレイ マネージャー (ユーザー スペース) -> ユーザー初期化 (または x セッション初期化)。

system init によって管理されるプロセスの設定ファイルは「/etc/init 」にあり、session init によって管理されるプロセスの設定ファイルは「/usr/share/upstart 」にあります( 1.12 以降の現在の新興バージョンに準拠)、これらの設定ファイルは、この記事で説明されているように、プロセスに関する多くの発掘された秘密の鍵となります。

階層をさらに深く理解する

Ubuntu は 2 種類のプロセスを認識します。

  1. 短命な仕事 (または働いて死ぬ仕事)。
  2. 長く続く仕事(または住み続けて働く仕事)。

システム上に作られる階層はプロセス間の依存関係によるもので、構成ファイルを見ることで理解できます。まず、システムを起動するプロセス間の単純な階層関係から始めて、それぞれの重要性を理解しましょう。

ブート階層

Init は、システムの電源投入時に開始される最初のプロセスであり、強制終了されることはなく、init が強制終了されるときのみであるため、ワークアンドステイ ジョブに分類されます。電源を切る、つまりinitのみが停止し、それもセッションごとに1回、電源が切れるときに行われます。電源投入時に、init はシステム上で最初のイベント、つまり起動イベントを生成します。 「/etc/init 」内の各設定ファイルには、プロセスの開始と停止を引き起こすイベントを定義する 2 行があります。これらの行は、次の図で強調表示されています。

これはプロセスfailsafe-x の構成ファイルであり、これらの開始条件と停止条件は、プロセスが開始されるイベントを記述します。 init プロセスによる起動イベントの生成時に、開始条件として起動を持つプロセスが並列実行されます。これは階層を定義するだけであり、起動時に実行されるすべてのプロセスは init の子になります。

起動時に開始されるプロセスは次のようにリストされており、これらはすべて作業と死ぬ作業です。

1ホスト名 – これは、/etc/hostname ファイルで定義されたホスト名をシステムに伝えるだけのプロセスです。

2kmod – カーネル モジュール、つまり /etc/modules ファイルからすべてのドライバーをロードします。

3mountall – このプロセスは多くのイベントを生成し、主にローカル ファイル システムとリモート ファイル システムを含む起動時のすべてのファイル システムをマウントします。

/proc ファイルもこのプロセスによってマウントされ、すべてのマウント作業の後、ファイルシステム イベントによって生成される最後のイベントが階層をさらに進めます。

4plymouth – このプロセスは mountall の起動時に実行され、システム起動時に次のような黒い画面が表示されるようになります。

5plymouth-ready – plymouth が起動していることを示します。

以下にメイン プロセスを示します。udev-fallback-graphics など、起動時に実行される他のプロセスも示します。ブート階層に戻ると、簡単に言うと、その後のイベントとプロセスは次のとおりです。

1init と起動イベントの生成。

2mountall はファイル システムをマウントし、plymouth は (mountall の起動とともに) スプラッシュ スクリーンを表示し、kmod はカーネル モジュールを読み込みます。

3 。 mountall によって生成された ローカル ファイルシステム イベントにより、dbus が実行されます。 (Dbus はシステム全体のメッセージ バスであり、ソケットを作成し、このソケットにメッセージを送信することで他のプロセスが相互に通信できるようにします。受信側はこのソケット上のメッセージをリッスンし、そのソケットに宛てられたメッセージをフィルターします)。

4ローカル ファイル システム と、開始された dbus およびローカル ファイル システム イベントでも実行されるプロセス ネットワークによって発生する静的ネットワークアップ イベントにより、ネットワーク マネージャーが実行されます。

5 。 mountall によって生成されたvirtual-filesystem イベントにより、udev が実行されます。 (udev は、デバイスのホットプラグを管理する Linux のデバイス マネージャーであり、/dev ディレクトリにファイルを作成し、それらを管理する責任もあります。) udev は、マウントオールが仮想マウントを完了したものを /dev ディレクトリに RAM、ROM などのファイルを作成します。 -filesystems は、/dev ディレクトリのマウントを示すイベント virtual-filesystem を生成しました。

6udev により upstart-udev-bridge が実行され、ローカル ネットワークが起動していることを示します。その後、mountall が最後のファイルシステムのマウントを完了し、ファイルシステム イベントを生成した後。

7ファイルシステム イベントと static-network-up イベントにより、rc-sysinit ジョブが実行されます。ここで、古い sysvinit と upstart の間の下位互換性が登場します。

9rc-sysinit は、システムのランレベルを伝える telinit コマンドを実行します。

10 。ランレベルを取得した後、init は「S」または「K」で始まるスクリプトを実行します (「S」が含まれるジョブを開始します)。 /etc/rcX.d ディレクトリ内の名前の先頭に「K」が付いているものを強制終了し、/etc/rcX.d ディレクトリ内にあるものを強制終了します (「X」は現在のランレベルです)。 。

この一連の小さなイベントにより、電源を入れるたびにシステムが起動します。そして、このプロセスのイベントトリガーが階層の作成を担う唯一のものです。

さて、上記への別のアドオンがイベントの原因です。どのプロセスがどのイベントを引き起こすかは、以下の行に示すように、プロセスの同じ構成ファイルでも指定されます。

上記はプロセスマウントオールの設定ファイルのセクションです。これは、それが発行するイベントを示します。イベントの名前は、「イベント」という単語の後に続きます。イベントは、上記のように設定ファイルで定義されたもの、または接頭辞「starting」、「started」、「stopping」、または「stopped」を付けたプロセス名にすることができます。

そこで、ここで 2 つの用語を定義します。

  1. イベント ジェネレータ: 設定ファイルに「emits xxx」という行があるイベント ジェネレータ。xxx は、所有または生成するイベントの名前です。
  2. イベント キャッチャー: 開始条件または停止条件が xxx であるか、イベント ジェネレーターの 1 つによって生成されたイベントで開始または停止するもの。

したがって、階層は以下に従い、プロセス間の依存関係は次のようになります。

Event generator (parent) -> Event catcher (child)

階層に複雑さを加える

ここまでは、 プロセス間の親子 依存関係の階層が、 単純な起動メカニズムを介したイベント トリガー メカニズムによってどのように構築されるかを理解したはずです。

さて、この階層は、1 つの子に対して 1 つの親だけを持つ 1 対 1 の関係ではありません。この階層では、1 つの子に対して 1 つ以上の親、または複数の子の親となる 1 つのプロセスが存在する場合があります。これはどのようにして実現されるのでしょうか??答えは設定ファイル自体にあります。

これらの行はプロセス – ネットワークから取得されており、ここでの開始条件は、多くのイベント、つまり ローカル ファイルシステムudevtriggerコンテナ< で構成されているため少し複雑すぎるように見えます。ランレベルネットワーク

ローカル ファイルシステムは mountall によって発行され、udevtrigger はジョブの名前です。コンテナ イベントは container-detect によって発行され、ランレベル イベントは rc-sysinit によって発行され、ネットワークもジョブです。

したがって、階層内では、プロセス ネットワーキングは機能を継続できないため、mountall、udevtrigger、container-detect の子になります (プロセスの機能は、プロセスの構成ファイルの script または exec セクションで定義されているすべての行です)。上記のプロセスがイベントを生成するまで
同様に、1 つのプロセスによって生成されたイベントが多数のプロセスによってキャッシュされている場合、1 つのプロセスを多数のプロセスの親にすることができます。

職種の区別

前に定義したように、私たちは短命 ( または働き続けて死ぬ 仕事) または長続きする (または働き続け ) 仕事のいずれかを行うことができますが、これらを区別する方法は何ですか?彼ら??

設定ファイルで「開始」条件と「終了」条件の両方が指定されており、その中に「タスク」という単語が含まれるジョブ。設定ファイルは、生成されたイベントで開始され、スクリプトまたは exec セクションを実行し(実行中は、それらの原因となったイベントをブロックします)、 その後ブロックされたイベントを解放して終了する即効性のある ジョブです。 。

設定ファイルに「停止」条件が含まれていないジョブは、存続期間が長いジョブまたは滞在して作業するジョブであり、終了することはありません。現在、滞在して働く仕事はさらに次のように分類できます。

  1. リスポーン条件がなく、root ユーザーによって強制終了できるもの。
  2. これらは設定ファイルにリスポーン条件が設定されているため、作業が完了しない限り、強制終了された後に再起動されます。

結論

したがって、LINUX の各プロセスはいくつかに依存しており、また、そのプロセスに依存するプロセスもいくつかあり、この関係は多対多であり、プロセスの他の詳細とともに upstart システムで指定されます。