systemdとは

systemdはカーネルが生成する最初のユーザプロセスで、Linuxの起動処理やシステム全体の管理を行います。
プロセス番号PID=1で、デーモン（メモリー上に常に待機している常駐プログラム）です。

要するに、パソコンの電源ボタン押してからシステムが起動するまでの間で誰よりも先人に立って
仕事をこなしていくリーダー的な存在です。

GRUB2によってHDDからメモリーにロードされたカーネルは、H/Wを認識できるようになった後、
PID=1のsystemdを起動する。
GRUB2はこちらの記事参照→作成中

【システム起動の流れ】

systemd のプロセス番号がPID=1であることを確認します

# ps aux | head -n 10
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root           1  0.0  0.3 175684 13976 ?        Ss   18:41   0:02 /usr/lib/systemd/systemd --switched-root --system --deserialize 17
root           2  0.0  0.0      0     0 ?        S    18:41   0:00 [kthreadd]
root           3  0.0  0.0      0     0 ?        I<   18:41   0:00 [rcu_gp]
root           4  0.0  0.0      0     0 ?        I<   18:41   0:00 [rcu_par_gp]
root           6  0.0  0.0      0     0 ?        I<   18:41   0:00 [kworker/0:0H-events_highpri]
root           9  0.0  0.0      0     0 ?        I<   18:41   0:00 [mm_percpu_wq]
root          10  0.0  0.0      0     0 ?        S    18:41   0:00 [rcu_tasks_rude_]
root          11  0.0  0.0      0     0 ?        S    18:41   0:00 [rcu_tasks_trace]
root          12  0.0  0.0      0     0 ?        S    18:41   0:00 [ksoftirqd/0]

systemdは【Unit】という単位でシステム起動処理をしている。
linuxを起動してしただけなのに、カーネルが既に218個の処理をメモリ上でしています
（電源を入れただけなのに裏ではでいろんな処理がされてるんですね）

従来のinit/upstartからsystemdへ

技術の進歩を振り返ると理解が深まるので軽く触れます。
CentOS6以前（2012年頃）までは、Linuxの起動処理はinit/upstartと呼ばれる仕組みで行われていました。
これが、CentOS7（2015年）以降全く違う新しい仕組みのsystemdに置き換わる。

systemdはinit以前の起動プロセスに影響しない。
図だけ見るとあまり変わっていないように見えるかもしれないが、
これは全く違う仕組みで起動処理にかかる速度も大幅に改善した。

今回は、systemdの動作の基礎となる【Unit】の概念を焦点を当てる。

initのデメリット

従来のinitの起動プロセスは、スクリプトで上から順番に直線的に起動していくので、
上流の起動で手間とると、以降のすべての実行するサービスが待たされてしまい時間がかかる。

systemdのメリット

従来のスクリプトを廃止し、【Unit】という単位で処理を管理する。
これまで/etc/rc.d/配下のスクリプトが実施していた処理の内容は、
全てUnitとして定義され直接systemdがunitを起動する。以下のプロセスを見ても、
initに比べて直線的ではなく、並列に起動しているのがわかる。

Unitの特徴

①スクリプトではなく設定ファイル
→Unitの設定をもとにsystemd自身が処理を実行する
②Unit間の依存・順序関係（並列処理）の定義
→「Aプロセス」を起動するには「Bプロセス」が必要など。

Unitは、「target」「mount」「service」「device」など、役割によってタイプがわかれていて、それぞれのunitは、依存関係が定義されている。
最初のプロセスPID=1としてsystemdが起動すると、「default.target」というUnitを頂点とする、依存関係のツリーを構築した後、依存するUnitを起動していく。

/default.target

$ vi /etc/systemd/system/default.target
[Unit]
Description=Graphical Interface
Documentation=man:systemd.special(7)
Requires=multi-user.target
Wants=display-manager.service
Conflicts=rescue.service rescue.target
After=multi-user.target rescue.service rescue.target display-manager.service
AllowIsolate=yes

上の場合、【requires=multi-user.target】と記述がある。
この意味は【default.target】と【multi-user.target】が必ず同時起動しないといけないという依存の定義である。Unit間の依存・順序関係の定義は以下を参照する。

このUnit間の依存関係の定義をdefault.targetの各々のunitと見比べると、
どういう依存関係になっているかが理解できる。ここからわかることが、
systemdは順序関係の情報をもとにして、複数のUnitをできるかぎり並列に起動していきます。

このように、systemdを利用すると、

・シェルスクリプトを使わずにsystemdが直接Unit（サービス）を起動する。
・Unitの起動処理を可能な限り並列化する。
・Unitの起動をオンデマンド化する。

という工夫にによって、システムの起動時間が圧倒的に短縮されます。

Unitの定義ファイルの配置ディレクトリは2か所

① /usr/lib/systemd/system/
システムのデフォルトの設定：
インストール済の RPM PKGで配布されたUnitの設定ファイル
② /etc/systemd/system/
ユーザ独自設定（管理者が作成・管理するUnitの設定ファイル）：
同名のファイルをここに配置するとこちらのファイルが優先される

用途別に様々な種類のUnitが存在

これはシステム起動状態を表す従来のrunlevelとtargetの対応表であるが、コマンドでも確認できる。

/usr/lib/systemd/system/runlevel*target

lrwxrwxrwx. 1 root root 15  9月 13 17:03 /usr/lib/systemd/system/runlevel0.target -> poweroff.target
lrwxrwxrwx. 1 root root 13  9月 13 17:03 /usr/lib/systemd/system/runlevel1.target -> rescue.target
lrwxrwxrwx. 1 root root 17  9月 13 17:03 /usr/lib/systemd/system/runlevel2.target -> multi-user.target
lrwxrwxrwx. 1 root root 17  9月 13 17:03 /usr/lib/systemd/system/runlevel3.target -> multi-user.target
lrwxrwxrwx. 1 root root 17  9月 13 17:03 /usr/lib/systemd/system/runlevel4.target -> multi-user.target
lrwxrwxrwx. 1 root root 16  9月 13 17:03 /usr/lib/systemd/system/runlevel5.target -> graphical.target
lrwxrwxrwx. 1 root root 13  9月 13 17:03 /usr/lib/systemd/system/runlevel6.target -> reboot.target

現在のtargetの確認する。

# systemctl get-default 
graphical.target

現在のgraphical.target（runlevel5）をmulti-user.targetのCLI ( runlevel=3 )ログインに変更する

# systemctl set-default multi-user.target 
Removed /etc/systemd/system/default.target.
Created symlink /etc/systemd/system/default.target → /usr/lib/systemd/system/multi-user.target.

現在のtargetが、multi-user.targetに変更になったことを確認

# systemctl get-default 
multi-user.target

メモリ上に常駐しているsystemdのデーモンを確認

# pstree -p | grep systemd
systemd(1)-+-ModemManager(893)-+-{ModemManager}(907)
           |-systemd(2132)-+-(sd-pam)(2136)
           |-systemd-journal(598)
           |-systemd-logind(875)
           |-systemd-machine(774)
           |-systemd-udevd(640)

systemdがまず最初にみるdefault.targetの設定ファイルを確認すると、シンボリックリンクになっています。

# ls -l /etc/systemd/system/default.target
lrwxrwxrwx. 1 root root 40 10月 19 00:57 /etc/systemd/system/default.target -> /usr/lib/systemd/system/graphical.target

つまり、Linuxをデフォルトで、graphical.target（GUI）操作できるようになっているのがわかる。

設定ファイルを追って依存・順序関係を把握する（教科書100回読むより絶対この方が理解できる）

# cat -n /etc/systemd/system/default.target	
    10	[Unit]
    11	Description=Graphical Interface
    12	Documentation=man:systemd.special(7)
    13	Requires=multi-user.target
    14	Wants=display-manager.service
    15	Conflicts=rescue.service rescue.target
    16	After=multi-user.target rescue.service rescue.target display-manager.service
    17	AllowIsolate=yes

systemdは、multi-user.targetを前提とするunitを探してそのunitを起動する(13行目)。
設定ファイルmulti-user.target内に記述された前提を見る

# cat -n /usr/lib/systemd/system/multi-user.target
    10	[Unit]
    11	Description=Multi-User System
    12	Documentation=man:systemd.special(7)
    13	Requires=basic.target
    14	Conflicts=rescue.service rescue.target
    15	After=basic.target rescue.service rescue.target
    16	AllowIsolate=yes

13行目、Requiresの設定ファイルbasic.target内に記述された前提を見る

# nl /usr/lib/systemd/system/basic.target  
     9	[Unit]
    10	Description=Basic System
    11	Documentation=man:systemd.special(7)
    12	Requires=sysinit.target
    13	Wants=sockets.target timers.target paths.target slices.target
    14	After=sysinit.target sockets.target paths.target slices.target tmp.mount

12行目、Requiresの設定ファイルsysinit.target内に記述された前提を見る

# nl /usr/lib/systemd/system/sysinit.target  
     9	[Unit]
    10	Description=System Initialization
    11	Documentation=man:systemd.special(7)
    12	Conflicts=emergency.service emergency.target
    13	Wants=local-fs.target swap.target
    14	After=local-fs.target swap.target emergency.service emergency.target

13行目、wantsの設定（＝可能な限り同時設定）local-fs.target swap.target

以上のことからsystemdは、以下の順で各unitを把握していることがわかる。

default.target >> multi-user.target >> basic.target >> sysinit.target

依存関係を確認するために、一つ一つ設定ファイルを追っていくのは骨が折れる。これを"systemctl list-dependencies" コマンドにより、systemdが認識する依存関係を表示できる

# systemctl list-dependencies default.target | grep target
default.target
● └─multi-user.target
●   ├─basic.target
●   │ ├─paths.target
●   │ ├─slices.target
●   │ ├─sockets.target
●   │ ├─sysinit.target
●   │ │ ├─cryptsetup.target
●   │ │ ├─local-fs.target
●   │ │ └─swap.target
●   │ └─timers.target
●   ├─getty.target
●   ├─nfs-client.target
●   │ └─remote-fs-pre.target
●   └─remote-fs.target
●     └─nfs-client.target
●       └─remote-fs-pre.target