CentOS 7 での systemd 管理システムの詳細な分析

CentOS システム起動プロセス:

POST -->ブート シーケンス -->ブートローダー -->カーネル initramfs(initrd) -->rootfs -->/sbin/init

初期プログラム:

CentOS 5: SysV の初期化

CetnOS 6: 新興企業

CentOS 7 : Systemd

Systemd の新機能:

System Sys V init スクリプトと LSB init スクリプトには互換性があります

システム起動時にサービスの並列起動を実装します。 ソケット/D-Bus アクティベーションおよびその他のテクノロジを使用してサービスを起動します。システム起動時間を短縮するために、systemd の目標は次のとおりです: 少数のプロセスで起動するできるだけ多くのプロセスを並行して開始します;

オンデマンドでプロセスをアクティブ化する; Systemd は、実際に要求された場合にのみサービスを開始する、オンデマンドで開始する機能を提供できます。サービスが終了すると、systemd はサービスをシャットダウンし、次回必要になったときに再起動できます。

システムのスナップショットと復元機能;

マウント ポイントと自動マウント ポイントの管理を開始します:

Systemd はシステム上のマウント ポイントを自己管理し、システム起動時に自動的にマウントできるようにします。 /etc/fstab ファイルと互換性があります;

トランザクション依存関係管理の実装:

systemd は、すべての関連サービスが相互依存やデッドロックなしで正常に開始できることを保証するために、「トランザクションの一貫性」の概念を維持します。

内生依存関係に基づいてサービス制御ロジックを定義します;

システムは、Linux カーネルの機能、つまり CGroup を使用して、プロセス追跡タスクを完了します。サービスを停止するとき、CGroup にクエリを実行することで、systemd は関連するプロセスがすべて見つかったことを確認し、それによってサービスを完全に停止できます。

ログ サービス: systemd には独自のログ サービス、journald が付属しています。このログ サービスの本来の設計は、既存の syslog サービスの欠点を克服することです。

システムの基本概念

ユニットのコンセプト:

システムの初期化中に行う必要があることがたくさんあります。 SSHD サービスの開始などのバックグラウンド サービスを開始する必要があり、ファイル システムのマウントなどの構成作業を行う必要があります。このプロセスの各ステップは、systemd によって構成単位、つまりユニットに抽象化されます。サービスは構成単位、マウント ポイントは構成単位、スワップ パーティションの構成は構成単位などと考えることができます。 systemd は、ハイブをいくつかの異なるタイプに分類します。ただし、systemd は急速に進化しており、新しい機能が常に追加されています。そのため、蜂の巣の種類は今後も増え続ける可能性があります。

service: mysqld などのバックグラウンド サービス プロセスを表します。これはよく使用されるカテゴリです;

socket: このハイブは、システムとインターネットのソケットをカプセル化します。現在、systemd はストリーミング、パケット、連続パケットの AF_INET、AF_INET6、および AF_UNIX ソケットをサポートしています。すべてのソケット ハイブには、対応するサービス ハイブがあります。最初の「接続」がソケットに入ると、対応するサービスが開始されます (例: nscd.socket は、新しい接続後に nscd.service を開始します)。

device : このハイブは、Linux デバイス ツリーに存在するデバイスをカプセル化します。 udev ルールでタグ付けされたすべてのデバイスは、systemd にデバイス ハイブとして表示されます。

マウント: このタイプのハイブは、ファイル システム構造階層内のマウント ポイントをカプセル化します。 Systemd はこのマウント ポイントを監視および管理します。たとえば、起動時に自動的にマウントしたり、特定の条件下で自動的にアンインストールしたりできます。 Systemd は /etc/fstab 内のすべてのエントリをマウント ポイントに変換し、起動時に処理します。

automount: このタイプのハイブは、システム構造階層内の自己マウント ポイントをカプセル化します。各自己マウント ハイブはマウント ハイブに対応しており、自動マウント ポイントにアクセスすると、systemd はマウント ポイントに定義されたマウント動作を実行します。

swap: マウント ハイブと同様に、スワップ ハイブはスワップ パーティションの管理に使用されます。ユーザーはスワップ ハイブを使用してシステム内にスワップ パーティションを定義し、これらのスワップ パーティションを起動時にアクティブ化できるようにします。

target: このハイブは、他のハイブの論理グループを提供します。彼らは実際には自分自身では何もせず、他のハイブを参照するだけです。これにより、構成単位を一元的に制御できます。これにより、おなじみの実行レベルの概念を実装できるようになります。たとえば、システムをグラフィカル モードにしたい場合は、多くのサービスと構成コマンドを実行する必要があります。これらの操作は、構成単位によって 1 つずつ表されます。これらすべての構成単位を 1 つのターゲットに結合するということは、これらすべての構成単位で次の操作を実行する必要があるということです。ターゲットによって表されるシステム実行状態に入るまでに 1 回。 (例: multi-user.target は、従来の SysV を使用するシステムのランレベル 3 に相当します)

timer: タイマー構成ユニットは、ユーザー定義の操作を定期的にトリガーするために使用されます。このタイプの構成ユニットは、atd や crond などの従来のタイミング サービスを置き換えます。

snapshot: ターゲット ハイブと同様に、スナップショットはハイブのセットです。システムの現在の動作状態を保存します。

依存関係:

ただし、systemd は依存関係から多数の起動タスクを削除し、それらを同時に起動できるようにします。ただし、タスク間に固有の依存関係を持つタスクが依然としていくつかあり、「ソケットのアクティブ化」(ソケットのアクティブ化)、D-Bus のアクティブ化、および autofs の 3 つの主要な方法を使用して依存関係を解消することはできません (詳細については、以降の説明を参照してください)。 3つの主要な方法）。たとえば、マウントはファイル システムにマウント ポイントが作成されるまで待機する必要があり、マウントは対応する物理デバイスの準備が完了するまで待機する必要もあります。この種の依存関係の問題を解決するために、systemd 構成ユニットは相互の依存関係を定義できます。

Systemd は、ハイブ定義ファイル内のキーワードを使用して、ハイブ間の依存関係を記述します。例: ユニット A はユニット B に依存しており、これはユニット B の定義の「A が必要」で表すことができます。このようにして、systemd は A が最初に開始され、次に B が開始されるようにします。

Systemd トランザクション:

Systemd はトランザクションの整合性を保証できます。 Systemd のトランザクション概念はデータベースのトランザクション概念とは異なり、主に複数の依存する構成ユニット間で循環参照が存在しないことを保証します。循環依存関係がある場合、systemd はサービスを開始できなくなります。ハイブ間には 2 種類の依存関係があるため、現時点では systemd がこの問題を解決しようとします: required は強い依存関係、want は弱い依存関係です。systemd は、wants キーワードで指定された依存関係を削除して、依存関係を解消できるかどうかを確認します。サイクル。修復できない場合、systemd はエラーを報告します。

Systemd は、このような構成エラーを自動的に検出して修復できるため、管理者のトラブルシューティングの負担が大幅に軽減されます。

ターゲットとランレベル:

systemd は、実行レベルの概念をターゲットに置き換え、柔軟性を高めます。たとえば、既存のターゲットを継承し、他のサービスを追加して独自のターゲットを作成できます。次の表は、systemd のターゲットと共通のランレベル間の対応関係を示しています。

Systemd の同時起動原理

前述したように、Systemd では、Avahi、D-Bus、livirtd、X11、HAL など、すべてのサービスが同時に開始されます。一見すると、これは少し問題があるように見えます。たとえば、Avahi には syslog サービスが必要です。Avahi と syslog は同時に開始されます。Avahi の方が速く起動すると仮定すると、syslog はまだ準備ができていませんが、Avahi は記録する必要があります。これは問題を引き起こさないでしょうか?

Systemd 開発者は、サービス間の相互依存性の性質を注意深く研究し、いわゆる依存関係が 3 つの特定のタイプに分類できること、およびそれぞれのタイプが対応するテクノロジを通じて実際に依存関係を排除できることを発見しました。

同時起動の原則の 1 つ: ソケット 依存関係の解決

サービスの依存関係の大部分はソケットの依存関係です。たとえば、サービス A はソケット ポート S1 を通じて独自のサービスを提供しますが、他のサービスがサービス A を必要とする場合は、S1 に接続する必要があります。したがって、サービス A がまだ開始されていない場合、S1 は存在せず、他のサービスは起動エラーを受け取ります。したがって、従来は、最初にサービス A を開始し、それが準備完了状態になるのを待ってから、それを必要とする他のサービスを開始する必要がありました。 Systemd は、事前に S1 を作成しておけば、サービス A が S1 を作成するのを待たずに、他のすべてのサービスを同時に開始できると考えています。サービス A が開始されていない場合、他のプロセスによって S1 に送信されたサービス リクエストは、実際には Linux オペレーティング システムによってキャッシュされ、他のプロセスはこのリクエストの場所で待機します。サービス A が起動して実行されると、キャッシュされたリクエストはすぐに処理され、すべてが正常に実行され始めます。

それでは、サービスは init プロセスによって作成されたソケットをどのように使用するのでしょうか?

Linux オペレーティング システムには機能があり、プロセスが fork または exec を呼び出して子プロセスを作成すると、親プロセスで開かれたすべてのファイル記述子が子プロセスに継承されます。ソケットもファイル ハンドルの一種です。プロセス A はソケットを作成できます。その後、プロセス A が exec を呼び出して新しい子プロセスを開始すると、ソケットの close_on_exec フラグがクリアされている限り、新しい子プロセスが作成されます。このソケットを継承できます。子プロセスから見えるソケットと親プロセスによって作成されたソケットは同じシステムソケットであり、ソケットが子プロセス自体によって作成されたかのように、違いはありません。

この機能は、以前は inetd というシステム サービスによって悪用されていました。 Inetd プロセスは、Telnet などのいくつかの共通ソケット ポートを監視する役割を果たします。ポート上で接続要求があると、inetd は telnetd プロセスを開始し、接続されたソケットを処理のために新しい telnetd プロセスに渡します。このように、システムに Telnet クライアント接続がない場合、telnetd プロセスを開始する必要はありません。 Inetd は多くのネットワーク サービスをプロキシでき、システム負荷とメモリ リソースを大幅に節約できます。対応するサービスは、実際の接続要求がある場合にのみ開始され、ソケットは対応するサービス プロセスに渡されます。

inetd と同様に、systemd は他のすべてのプロセスの親プロセスです。最初に必要なソケットをすべて確立し、次に exec を呼び出すときにそのソケットを新しいサービス プロセスに渡し、新しいプロセスはそれを直接使用します。ソケットは次のとおりです。サービスされました。

同時起動の原則 2: D-Bus 依存関係の解決

D-Bus はデスクトップ バスの略語で、低遅延、低オーバーヘッド、高可用性を備えたプロセス間通信メカニズムです。アプリケーション間の通信だけでなく、アプリケーションとオペレーティング システム カーネル間の通信にも使用されることが増えています。最新のサービス プロセスの多くは、外部サービスを提供するためのプロセス間通信メカニズムとしてソケットの代わりに D-Bus を使用します。たとえば、Linux ネットワーク構成を簡素化する NetworkManager サービスは、D-Bus を使用して他のアプリケーションやサービスと対話します。電子メール クライアント ソフトウェアの進化では、それに応じて処理するために、D-Bus を通じて NetworkManager サービスからネットワーク ステータスの変更を取得できます。

D-Bus は、いわゆる「バスアクティベーション」機能をサポートしています。サービス A がサービス B の D-Bus サービスを使用する必要があり、サービス B が実行されていない場合、サービス A がサービス B の D-Bus を要求すると、D-Bus はサービス B を自動的に開始できます。サービス A によって発行されたリクエストは D-Bus によってキャッシュされ、サービス A はサービス B の準備ができるまで待機します。この機能を使用すると、D-Bus に依存するサービスを並行して開始できます。

同時起動の 3 番目の原則: ファイル システムの依存関係の解決

システム起動プロセス中、ファイル システム関連のアクティビティが最も時間がかかります。たとえば、ファイル システムのマウント、ファイル システム上でのディスク チェック (fsck) の実行、およびディスク クォータ チェックはすべて非常に時間がかかります。オペレーション。この作業が完了するのを待っている間、システムはアイドル状態になります。ファイル システムを使用したいサービスは、開始する前にファイル システムの初期化が完了するまで待つ必要があるようです。しかし、systemd は、この依存関係も回避できることを発見しました。

Systemd は autofs の設計思想を参照しており、ファイル システムに依存するサービスとファイル システム自体の初期化が同時に動作できるようにします。 autofs は、カーネル オートマウンタ モジュールのサポートにより、マウント操作をトリガーする前に、ファイル システムのマウント ポイントが実際にアクセスされる時期を検出できます。たとえば、「/misc/cd/file1」に対して open() システム コールが実行された場合、/misc/cd はまだマウント操作を行っていないため、open() コールは中断されて待機します。カーネルは autofs に通知し、autofs がマウント操作を実行します。このとき、open()システムコールに制御が戻り、ファイルは通常通りオープンされます。

Systemd は autofs の実装を統合します。システムのマウント ポイント (/home など) については、システムの起動時に、systemd によって一時的な自動マウント ポイントが作成されます。この時点では、/home の実マウントデバイスはまだ起動しておらず、実マウント操作も実行されておらず、ファイルシステムの検出もまだ完了していません。ただし、このディレクトリに依存するプロセスはすでに同時に開始することができ、その open() 操作は systemd に組み込まれた autofs によってキャプチャされ、open() 呼び出しが中断されます (これによりスリープ状態が中断される可能性があります)。その後、実際のマウント操作が完了し、ファイル システムの検出が完了すると、systemd は自動マウント ポイントを実際のマウント ポイントに置き換え、open() 呼び出しを返します。その結果、ファイル システムに依存するサービスとファイル システム自体を同時に開始できます。

もちろん、「/」ルート ディレクトリへの依存は、実際にはシリアルに実行する必要があります。これは、systemd 自体も / に格納されており、システム ルート ディレクトリがマウントされてチェックされるまで待つ必要があるためです。

ただし、/home などのマウント ポイントの場合、この同時実行によりシステムの起動速度が向上します。特に /home がリモート NFS ノードや暗号化されたディスクなどである場合、起動には長い時間がかかります。この場合、同時起動により、この期間中システムは何もすることがなく、この空き時間を利用してより多くの起動プロセスを実行できるため、全体としてシステムの起動時間が短縮されます。

システム 使用法

以下は、技術担当者のさまざまな役割に基づいた systemd の使用法を簡単に紹介します。この記事は、systemd の使用方法を一般的に理解していただくために、簡単な説明のみを目的としています。具体的な詳細が多すぎて、短い記事ではカバーできません。読者はさらに systemd ドキュメントを自分で参照する必要があります。

単元 ファイルの書き込み

開発者が httpd などの新しいサービス プログラムを開発する場合、UpStart の作業構成ファイルと同様に、systemd でサービスを管理できるように、その構成ユニット ファイルを作成する必要があります。このファイルでサービスを起動するためのコマンド ライン構文と、他のサービスへの依存関係を定義します。

さらに、systemd には多くの機能があり、サービスの管理だけでなく、マウント ポイントの管理、スケジュールされたタスクの定義などにも使用されることを以前に学びました。これらのタスクは、対応するハイブ ファイルを編集することで完了します。ここではハイブ ファイルの例をいくつか示します。

次は、SSH サービスの構成単位ファイルです。サービス構成単位ファイルには、ファイル名のサフィックスとして .service が付いています。

[root@kalaguiyin システム]# cat/usr/lib/systemd/system/sshd.service

＃＃＃[ユニット]＃＃＃

説明=OpenSSH サーバー デーモン

After=network.target sshd-keygen.service

Wants=sshd-keygen.service

#[ユニット]部品、説明情報

＃＃＃[サービス]＃＃＃

環境ファイル=/etc/sysconfig/sshd

ExecStart=/usr/sbin/sshd -D $OPTIONS

ExecReload=/bin/kill -HUP $MAINPID

KillMode=プロセス

再起動=失敗時

再起動秒=42秒

#[サービス] 定義、ExecStartPre はサービスを開始する前に実行する必要があるコマンドを定義します。

#ExecStart は、サービスを開始するための特定のコマンド ライン構文を定義します。

＃＃＃[インストール]＃＃＃

WantedBy=マルチユーザー.ターゲット

#[install] セクション: WangtedBy は、このサービスがマルチユーザー モードで必要であることを示します。

次に、multi-user.target を見てみましょう:

[root@kalaguiyin システム]# catmulti-user.target

＃＃＃[ユニット]＃＃＃

説明=マルチユーザー システム

Documentation=man:systemd.special(7)

Requires=basic.target

競合=レスキュー.サービスレスキュー.ターゲット

After=basic.targetrescue.servicerescue.target

AllowIsolate=はい

# Requires 定義は、multi-user.target が開始するときは、basic.target も開始する必要があり、さらに、basic.target が停止するときは、multi-user.target も停止する必要があることを示しています。次に、basic.target ファイルを見ると、sysinit.target

も指定されていることがわかります。

# 他のユニットもそれに応じて開始する必要があります。同様に、sysinit.target には他のユニットも含まれます。このようなレイヤーごとのリンク構造を使用すると、最終的にはマルチユーザー モードをサポートする必要があるすべてのコンポーネント サービスが初期化され、開始されます。

＃＃＃[インストール]＃＃＃

エイリアス=default.target

# エイリアス定義とは、systemctl の実行時にこのエイリアスを使用してこのユニットを参照できるように、このユニットのエイリアスを定義することを意味します。

また、/etc/systemd/system ディレクトリには *.wants などのディレクトリも表示されます。このディレクトリに配置された構成ユニット ファイルは、[Unit] セクションのwants キーワードに相当します。ユニットが開始されると、これらのユニットも開始する必要があります。たとえば、自分で作成した foo.service ファイルを multi-user.target.wants ディレクトリに置くだけで、毎回デフォルトで起動されるようになります。

[root@kalaguiyin システム]# pwd

/etc/systemd/system

[root@kalaguiyin システム]# ls

basic.target.wants display-manager.service

bluetooth.target.wants

dbus-org.bluez.service graphical.target.wants

printer.target.wants sockets.target.wants

spice-vdagentd.target.wants .target.wants

sys-kernel-debug.mout ファイルをもう一度見てみましょう。このファイルはファイル マウント ポイントを定義します:

[root@kalaguiyin システム]# 猫

sys-kernel-debug.mount

＃＃＃[ユニット]＃＃＃

説明=デバッグ ファイル システム

Documentation=https://www.kernel.org/doc/Documentation/filesystems/debugfs.txt

Documentation=http://www.freedesktop.org/wiki/Software/systemd/APIFileSystems

DefaultDependency=no

ConditionPathExists=/sys/kernel/debug

前=sysinit.target

＃＃＃[マウント]＃＃＃

What=debugfs

どこ=/sys/kernel/debug

Type=debugfs

このハイブ ファイルはマウント ポイントを定義します。マウント ハイブ ファイルには [Mount] 構成セクションがあり、What、Where、Type の 3 つのデータ項目が含まれています。これらはマウント コマンドに必要です。例の構成は次のマウント コマンドと同等です:

mount –t debugfs /sys/kernel/debug debugfs

Systemd

システム管理:

systemd の主なコマンド ライン ツールは systemctl です。 ほとんどの管理者は、service、chkconfig、telinit コマンドの使用など、システム サービスと init システムの管理にすでに精通しているはずです。 systemd も同じ管理タスクを実行しますが、コマンド ツール systemctl の構文は異なります。

サービス開始

systemctl は、図 1 に示すように httpd.service を開始します:

＃＃＃故障中＃＃＃＃＃＃

systemctl は、図 2 に示すように httpd.service を停止します:

サービスの再起動

systemctl restarthttpd.service (図 3 に示す):

リロードサービス

systemctl reloadhttpd.service

条件付き再起動

systemctl condrestarthttpd.service

ステータスビュー

systemctl statushttpd.service

開始または停止できるサービスをリストします。

systemctl リストユニットファイル –type=service

起動時にサービスを開始するように設定する

chkconfig httpd オン

systemctlenablehttpd.service

サービスの起動をキャンセルします;

systemctl disablehttpd.service

現在の環境でサービスが有効または無効に構成されているかを確認します。

systemctl は有効ですhttpd.service;echo $?

各実行レベルでのサービスの有効化と無効化を出力します

systemctl リストユニットファイル –type=service

サービスが有効または無効になるランレベルをリストします。

ls /etc/lib/systemd/system/*.wants/httpd.service

ユーザー実行レベルの変更:

systemctl isolatemulti-user.target

multi-user.target == 3 番目の実行レベル

graphical.target == 5 番目の実行レベル

runlevel3.target シンボリック リンク、multi-user.target を指す

runlevel5.target シンボリック リンク (graphical.target を指す)

デフォルトのランレベルを変更します:

[root@kalaguiyinsystem]# systemctl set-default multi-user.target

rm'/etc/systemd/system/default.target'

ln -s'/usr/lib/systemd/system/multi-user.target''/etc/systemd/system/default.target'

上記の操作の本質は、/usr/lib/systemd/system/default.target を削除し、ターゲット レベルのターゲット ファイルを /etc/systemd/system/default.target ファイルにリンクすることです。

systemd はもはや単なる初期化システムではありません:

systemd

は、ネットワーク構成、

ロケール

管理、システム カーネル モジュールの管理など、システムの他の管理構成も担当します。積み込みなど

Systemd は sysvinit のすべての機能を置き換えるという優れた仕事をしていますが、これに満足しているわけではありません。 init プロセスはシステム内のすべてのプロセスの親プロセスであるため、systemd は、スケジュールされたタスク (以前は crond によって完了されていた) やセッション管理 (以前は ConsoleKit/PolKit によって管理されていた) など、他のサービスによって提供されていた機能を提供するのに非常に適しています。 。）。この記事の表面的な紹介から判断すると、Systemd はすでに多くのことに取り組んでいますが、まだ発展途上です。これは徐々に、多くのシステム管理タスクを処理できる多機能なシステム環境になり、オペレーティング システムとみなす人もいます。これは Linux 管理の標準化に最適です。

以上がCentOS 7 での systemd 管理システムの詳細な分析の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。