「CentOS7構築・運用・管理パーフェクトガイド」
systemdはシステム立ち上げの初期段階で、sysinit.targetより前に
systemd-journald.serviceとsystemd-udevd.serviceを開始する。また、multi-user.targetより前にsystemd-logind.serviceを開始する。
これら3つのサービスは、STATE（設定状態）がstaticに設定され、systemctlコマンドによるenableおよびdisableの設定はできない。
systemd-journald.serviceは、systemd-journaldデーモンを起動
systemd-udevd.serviceは、systemd-udevdデーモンを起動
systemd-logind.serviceは、systemd-logindデーモンを起動
# ps -ef |grep "/usr/lib/systemd/systemd-"
root 561 1 0 2月12 ? 00:00:00 /usr/lib/systemd/systemd-journald
root 582 1 0 2月12 ? 00:00:00 /usr/lib/systemd/systemd-udevd
root 722 1 0 2月12 ? 00:00:00 /usr/lib/systemd/systemd-logind
[P.148]
systemd-udevd.service
/devの下にデバイスファイルを動的に作成、削除するサービス
カーネルはシステム起動時あるいは稼働中に接続あるいは切断を検知したデバイスを/sysの下のデバイス情報に反映させ、ueventをsystemd-udevdデーモンに送る。
systemd-udeevdデーモンはueventを受け取ると、/sysの下のデバイス情報を取得し、
/etc/udev/rules.dと/lib/udev/rules.dの下の.rulesファイルに記述されたデバイス作成ルールに従って、/devの下のデバイスファイルを作成あるいは削除する。
図１ udevdによるデバイスファイルの作成と削除
・/lib/udev/rules.dディレクトリ
デフォルトのudevルールを記述したファイルが配置されている。ほとんどはudevパッケージからインストールされたファイル。ルールをカスタマイズする場合は、このディレクトリの下のファイルではなく、/etc/udev/rules.dディレクトリの下のファイルを編集する。
・/etc/udev/rules.dディレクトリ
カスタマイズされたudevルールを追記述したファイルが配置されている。ほとんどはudev以外のパッケージによってインストールされたファイル。管理者がudevルールをカスタマイズする場合は、このディレクトリの下のファイルを編集する。
udevの管理コマンドであるudevadmコマンドは、サブコマンドの指定により、①udevに対するデバイス情報の問い合わせ、②カーネルイベントのリクエスト、③イベントキューの監視、④udevdデーモンの内部ステートの変更、⑤カーネルのueventとudevルールによって処理されるイベントの監視とデバイスの表示、⑥イベントのシミュレートを行うことができる。
【課題】
udevadmと/procや/sys内の情報を見て、デバイスが認識されてデバイスファイルが生成されるまでの流れを確認してみる。
SysVinitでは、起動初期にmknodをラップするrcスクリプトがあった。
※下記はOpenSuSE11.4の場合
すぜ> find /etc/init.d -type f | while read line;do grep mknod $line \
&& echo "ファイル名=$line";done
mknod -m 0600 /dev/xconsole p
ファイル名=/etc/init.d/syslog
echo /bin/mknod -m600 $ROOTFS_BLKDEV b $((rootmajor)) $((rootminor))
/bin/mknod -m600 $ROOTFS_BLKDEV b $((rootmajor)) $((rootminor))
ファイル名=/etc/init.d/boot.rootfsck
test -c /dev/null || /bin/mknod -m 666 /dev/null c 1 3
ファイル名=/etc/init.d/boot
mknod -m 0600 /dev/$DEVICE c 10 $MINOR
ファイル名=/etc/init.d/autofs
/sbin/vgscan --mknodes
ファイル名=/etc/init.d/boot.lvm
[P.149]
systemd-logind.service
systemd-logind.serviceは、ユーザのログインを管理するサービス。
ユーザセッションの追跡及びセッションで生成されるプロセスの追跡、シャットダウン/スリープ操作に対するPolicyKitベースでの認可、デバイスへのアクセスに対する認可等を行う。
・各ログインの仕方ごとのログインシーケンス
- ディスプレイマネージャからのシーケンス
例えば、物理マシーンに直接接続されたコンソールからrunlevel5で起動しているOSにログインする場合
図２ gdmからのログインシーケンス
gdmはsystemd-logindデーモンを参照し、systemd-logindデーモンはpolkit.serviceから起動されるpolkitdデーモンをD-Busを介して参照する。
VNCビューアからVNCサーバにログインする場合
---調査中---
- 仮想端末（/dev/tty1）からのログインシーケンス
例えば、物理マシーンに直接接続されたコンソールからのログイン runlevel3で起動しているOSにログインの場合
図３ ttyからのログインシーケンス
従来からあるagetty、login等のプログラムを使用する。子のシーケンスのなかではsystemd-logindサービスは直接は参照されないが、systemd-logindデーモンはカーネルの/sysを監視して、ユーザセッションの追跡およびセッションで生成されるプロセスの追跡を行う。
なお、multi-user.targetの場合はpolkit.serviceは停止する。
- 仮想端末（/dev/pts/0）からのログインシーケンス
sshログインの場合
---調査中---
【課題】
・policykitやpolkitdって何？
・D-Busがまだよくわかってない
・acpiとsystemdの関係
acpi：周辺機器などの電力制御管理を行えるように定められたインターフェースの仕様。
https://www.weblio.jp/content/ACPI
・apicとsystemdの関係
apic：APICとは、PIC（Programmable Interrupt Controller）をより高度化させ、複雑な構造と大規模な出力を備えた割り込みコントローラのことである。SMP（Symmetric Multi-Processor）システムで用いられる。Intelのx86アーキテクチャのマイクロプロセッサに搭載されている割り込みコントローラ。
https://www.weblio.jp/content/APIC
[P.150]
システムシャットダウンとリブート
・sync後、systemdを呼び出したシャットダウン
systemctl poweroff
init 0
・sync後、systemdを呼び出したリブート
systemctl reboot
init 6
・sync後、systemdを呼び出さないシャットダウン
reboot -f
・sync後、systemdを呼び出さないリブート
poweroff -f
halt -f
【課題】
・systemdを呼び出したシャットダウン、リブートって何がおいしいの？
→systemdによる停止シーケンスが実行される。systemdによる停止シーケンスが実行されないと、一部のデータが失われる危険がある
→systemdによる停止シーケンスを具体的に調べよう
→systemdによる停止シーケンスはどのようにしてデータが失われる危険を防止しているのか？
・shutdownコマンドは？
・telinitコマンドは？
→CentOS7では互換性のためだけに残ってて非推奨らしい。
・デーモンの停止シーケンス
どんな処理をどんな順序で行うのか？pidファイルやlockファイルの削除、一時ファイルのデータへの反映、メモリ内オブジェクトのファイルへの反映、一時データの削除、その他永続性あるデータの整合性を保ちつつ退避など？ 接続中のセッションが切れるのを待ってから停止、
比較的時間のかかるI/O処理（数十秒から数分以上）の途中だった場合はどうなるの？
・デーモンどうしの停止順序、依存関係
・HAクラスタ
セッション情報はフェールオーバやフェールバック先に引き継ぐの？それとも強制的にリセットしちゃうの？ トランザクション中の場合はどうするの？
・負荷分散クラスタ
パーシステンスなどのセッション情報は他のクラスタメンバーに引き継ぐの？
nginx.serviceのユニット設定ファイル
# cat /usr/lib/systemd/system/nginx.service
[Unit]
Description=nginx - high performance web server
Documentation=http://nginx.org/en/docs/
After=network-online.target remote-fs.target nss-lookup.target
Wants=network-online.target
[Service]
Type=forking
PIDFile=/run/nginx.pid
ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf
ExecStart=/usr/sbin/nginx -c /etc/nginx/nginx.conf ←①
ExecReload=/bin/kill -s HUP $MAINPID ←②
ExecStop=/bin/kill -s QUIT $MAINPID ←③
[Install]
WantedBy=multi-user.target ←④
④の指定により、nginx.serviceをenableにすると、
/etc/systemd/system/multi-user.target.wantsディレクトリの下にhttpd.serviceへのシンボリックリンクが作成される。disableにするとシンボリックリンクは削除される。
「RHEL7 システム管理者のガイド」
※いつまでも評論家してるだけではらちがあかないのでとりあえず読み進めるんご
RHEL7 システム管理者のガイド 第9章 systemd によるサービス管理
[9.1. systemd の概要]
・Systemd はSysV initスクリプトと後方互換するように設計されており、①起動時のシステムサービスの並行スタートアップや②デーモンのオンデマンドのアクティベーション、③システム状態のスナップショットのサポート、④依存ベースのサービス管理論理などの多くの機能を提供する。
[9.1.1. 主な特長]
・ソケットベースのアクティベーション — 起動時に systemd は、このタイプのアクティベーションをサポートするすべてのシステムサービス用のリスニングソケットを作成し、サービスが開始するとすぐにこれらのソケットをサービスに渡します。これで systemd がサービスを並行で開始できるだけでなく、サービスが利用可能でない間に送信されたメッセージを失うことなくサービスの再起動が可能になります。これは、対応するソケットがアクセス可能なままで、すべてのメッセージがキューに登録される。
・バスベースのアクティベーション — プロセス間の通信に D-Bus を使用するシステムサービスは、クライアントアプリケーションがシステムサービスとの通信を試みる初回にオンデマンドでスタートできます。Systemd は、バスベースのアクティベーションに D-Bus サービスファイル を使用します。
・デバイスベースのアクティベーション — デバイスベースのアクティベーションをサポートするシステムサービスは、特定のタイプのハードウェアがプラグインするか利用可能になった際に、オンデマンドでスタートできます。Systemd は、デバイスベースのアクティベーションに device units を使用します。
・パスベースのアクティベーション — パスベースのアクティベーションをサポートするシステムサービスは、特定のファイルもしくはディレクトリーの状態が変更される際にオンデマンドでスタートできます。Systemd は、パスベースのアクティベーションに path units を使用します。
・システム状態のスナップショット — Systemd は、一時的にすべての unit の現状を保存するか、動的に作成されたスナップショットから以前のシステムの状態を復元することができます。システムの現状を保存するために systemd は、動的に作成された snapshot units を使用します。
・マウントおよびオートマウントポイントの管理 — Systemd は、マウントポイントおよびオートマウントポイントを監視、管理します。Systemd はマウントポイントには mount units を、オートマウントポイントには automount units を使用します。
・アグレッシブな並列化 — ソケットベースのアクティベーションを使用するため、systemd は すべてのリスニングソケットが配置されると同時に並行してシステムサービスを開始できます。オンデマンドのアクティベーションをサポートするシステムサービスと組み合わせることで、並行アクティベーションはシステム起動に必要となる時間を大幅に短縮します。
・トランザクション unit アクティベーション論理 — unit のアクティベーションまたは非アクティブ化の前に、systemd はその依存関係を計算して一時的なトランザクションを作成し、このトランザクションの一貫性を検証します。トランザクションに一貫性がない場合、systemd は自動的にこれを正そうとし、エラーをレポートする前に必須でないジョブを削除しようと試みます。
・SysV init との後方互換性 — 『Linux Standard Base Core Specification』 にあるように、Systemd は SysV init スクリプトをサポートします。これにより、systemd サービス unit への更新パスが容易になります。
・・・全部丸写しｗｗｗ
[9.1.2. 互換性の変更点]
・systemd システムおよびサービスマネージャーは、SysV init および Upstart とほぼ互換するように設計されています。
・systemctl ユーティリティーは、カスタマイズされたコマンドをサポートしません。start、stop、および status といった標準のコマンドに加えて、SysV init スクリプトのオーサーは、任意の多数のコマンドに対するサポートを実装して追加機能を提供することができます。たとえば、Red Hat Enterprise Linux 6 の iptables の init スクリプトは、panic コマンドとの実行が可能です。
・systemctl ユーティリティーは、systemd が開始していないサービスとは通信しません。systemd がシステムサービスを開始すると、メインプロセスの ID を保存してそれを追跡します。すると systemctlユーティリティーはこの PID を使ってクエリーを行い、サービスを管理します。このため、ユーザーがコマンドラインで特定のデーモンを直接開始すると、systemctl は最新の状態を判断したり、これを停止したりすることができません。
・システムサービスは標準の入力ストリームからは読み込みができません。systemd がサービスを開始すると、標準入力を /dev/null に接続し、ユーザーとのインタラクションを防ぎます。
・システムサービスは、(HOME および PATH 環境変数といった) コンテキストを開始したユーザーやそのセッションからコンテキストを継承しません。各サービスは、クリーンな実行コンテキストで実行されます。
・SysV init スクリプトを読み込む際に Systemd は、Linux Standard Base (LSB) ヘッダーにコード化されている依存関係情報を読み込み、ランタイム時に解釈します。
→ELFとLSBがよくわかってないｗｗｗ