「Systemd」を理解するーシステム起動編ー

公開日： 2014/06/28 : 最終更新日：2014/06/29 Linux, Systemd, 技術

2014年6月10日、とうとうRHEL7が正式リリースを迎えた。RHEL7での変更点については、このスライドに詳しく記載されているが、今回の記事では特に大きな変更点である「Systemd」について解説していきたいと思う。

Systemdは従来のinit/Upstartの代替であり、非常に高速なシステム起動・終了や、様々なシステム管理機能を提供する。ただし、その仕組みや管理方法は従来のinit/Upstartとは大きく異なり、init/Upstartに慣れ親しんだ方は習熟に時間を要するだろう。

Systemdは様々な機能と役割を持っているが、今回の記事ではSystemdによるシステム起動に焦点を当てた内容とさせていただく。Systemdを利用したシステム管理については、後日別の記事を投稿する予定だ。なお、当記事はRHEL7のベースとなっているFedora19を元に動作確認させていただいた。

それでは、Systemdの世界に飛びだそう！

Systemdとは

Systemdとは従来のSysVinitやUpstartの代替となるデーモンだ。ただし、Systemdはプロセスの起動だけではなく、プロセスの管理や様々なトリガーによるプロセス起動など、その適用範囲は広範だ。Systemdは以下の特徴を持つ。

高速なシステム起動と終了
（Upstartよりも）高い並列度でプロセスを扱うため素早い起動・終了ができる
設定ファイルによるシステム管理の共通化
シェルスクリプトは利用しないため、一度使い方を覚えれば様々な場面に対応できる
柔軟なプロセス起動
様々な方法でプロセス起動できる
・タイマーによる起動（cron代替）
・socketへの通信検出によるプロセス起動（xinetd代替）
・所定のパスへのファイル作成をトリガーとしたプロセス起動 etc…
cgroupsによるプロセス管理
cgroupsによるリソースの利用制限や、優先度設定によるプロセス管理を実現できる

それではSystemdによるシステム起動プロセスを紐解いていこう。

ブートプロセスにおけるSystemdの影響範囲

先ずはSystemdそのものが起動されるタイミングについて記載しておく。Systemdはinit/Upstartの代替だから、BIOS/UEFIから始まるブートプロセスでの立ち位置は旧来のinit/Upstartと同様である。すごく大雑把に書くと以下のようなイメージである。

Systemdはinitの代替であるから、init以前の起動プロセスに影響しない。ちなみに、Fedora19上にも/sbin/initは存在するが、これは従来のinitではなく、systemdへのシンボリックリンクとなっている。

$ cat /etc/redhat-release 
Fedora release 19 (Schrödinger’s Cat)

$ #/sbin/initは存在するがSystemdへのシンボリックリンクとなっている
$ ls -l /sbin/init
lrwxrwxrwx. 1 root root 22  6月 16 22:40 /sbin/init -> ../lib/systemd/systemd

Unitを理解する

Systemdによる具体的な起動プロセスを見る前に、Systemdで重要な概念となるUnitについて解説する。

Systemdにおける処理の単位 – Unitとは？

システム起動がいかなる仕組みによって実現されようが、”システムを起動するためにやらなければいけないこと”（ネットワークの初期化や必要に応じたプロセス起動など）は変わらない。システム起動を実現する仕組みの違いは、これらの処理を”どうやって管理し、どのように実行するか”という点にある。
init/Upstartでは、これらの処理をrc.sysinitや、/etc/rc.dのスクリプトで定義していたのに対し、Systemdでは”Unit”という単位で管理する。Unitは以下のような特徴を持っている。

スクリプトではなく設定ファイルである
Unitの設定を元にSystemd自身が処理を実行する
Unit同士の関係を定義できる
Aプロセスを起動するためにはBプロセスが必要、というような関係を定義できる
SystemdはUnit間の関係を読み取り、最適な起動順を選択する（詳細は後述）
用途別に様々な種類が存在する
”プロセスに関する設定”、”マウントに関する設定”等、様々な種類がある
Unitの種類はUnitファイルの拡張子で判断する

主なUnitの種類は以下の通りだ。個々の種類は拡張子で見分けることができ、用途に応じた様々な設定ができるようになっている。

Unitの種類（拡張子）	設定内容
.service	プロセスの起動／停止に関する設定ファイル名は「プロセス名.service」となる (httpd.service、sshd.serviceなど）
.mount	ファイルシステムのマウント／アンマウントに関する設定ファイル名は「マウントポイント.mount」となる /etc/fstabの内容を元にSystemdが自動作成する
.socket	ソケットの監視設定 ”ソケットへの接続を検出すると特定のプロセスを起動”といった動作を実現可（xinet.dの代替にできる）
.device	システムが認識しているデバイス情報を保持する udevデーモンによって自動作成される
.path	パスの監視設定 ”監視ディレクトリにファイルが置かれたらサービス起動”といった動作を実現可
.target	複数のUnitをとりまとめるUnit

例えば、apacheと対応するUnitであるhttpd.serviceは以下のように定義される。従来のinit/Upstartでは、このようなhttpdに関する起動設定はスクリプト（/etc/rc.d/init.d/httpd）として定義されていただろう。httpd.serviceでは単なる設定ファイルとなっていることが分かる。

$ cat /usr/lib/systemd/system/httpd.service
[Unit]
Description=The Apache HTTP Server
After=network.target remote-fs.target nss-lookup.target

[Service]
Type=notify
EnvironmentFile=/etc/sysconfig/httpd
ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND
ExecReload=/usr/sbin/httpd $OPTIONS -k graceful
ExecStop=/usr/sbin/httpd $OPTIONS -k graceful-stop
KillSignal=SIGCONT
PrivateTmp=true

[Install]
WantedBy=multi-user.target

httpd.serviceはプロセスに関するUnitに分類されるため、プロセス関連の設定項目を保持するが、.mountなどのその他Unitは、個々の用途に応じた設定項目を保持している。

Unitファイルの格納先

Unitファイルの格納先は以下の2カ所である。

ディレクトリ	設定内容
/usr/lib/systemd/system	インストール時の初期設定当ディレクトリ内のUnitは編集しない
/etc/systemd/system	ユーザによる個別設定デフォルトの設定を変更する場合は、当ディレクトリにUnitファイルをコピーして編集する（Systemdは当ディレクトリのUnitを優先する）

インストール直後の設定と、個別の設定を格納するディレクトリが分かれている。個別の設定を行う場合は/etc/systemd/systemを利用しよう。

Unit間の関係定義

Systemdでは、Unit間の関係を定義できる。関係には”依存”と”起動順”の2種類がある。

依存
プロセス同士が”同時に起動するべきか”を定義する。
例えばプロセスAがBに依存（プロセスAは、プロセスBと同時に起動されるべき）と定義した場合、プロセスAが起動対象となった場合にプロセスBも同時に起動される。
依存はあくまでも”同時起動されるべきか”を定義するものであり、プロセスの起動順（プロセスA、Bのどちらを先に起動するか）は表現しない。
依存には”Wants”（可能な限り同時起動）、”Requires”（必ず同時起動）、”Comflict”（同時起動しない）などがある。
起動順
プロセス起動の前後関係を定義する。
例えば”プロセスAはプロセスBよりも先に起動するべき”といった関係を定義できる。
順序関係は”After”、”Before”などがある。

Systemdでは、依存と起動順を別々に定義することによって、Upstartよりもプロセス起動の並列度を上げている。例えば、依存関係があるものの起動順の指定が無いプロセスA、Bが存在したとする。この場合、Systemdは”システム起動完了時点でプロセスA、Bが起動状態となっていれば良い”と判断できるため、プロセスA、Bを並行して起動するといった動作が実施可能となるのだ。

依存関係と順序関係の定義方法は以下の通りだ。

関係	分類	内容と設定方法
Wants	依存	強制力の無い依存関係。 Systemdはプロセスの同時起動を試みるが、依存先の起動に失敗した場合であっても、依存元の起動は引き続き実施する。 ■「 AはBに依存する」の定義方法方法1．AのUnit定義ファイルに直接設定を記述 A.service ------------------------------------------- [Unit] Wants=B.service --------------------------------------------------- 方法2．AのwantsディレクトリにBのシンボリックリンクを作成 A.serviceファイルが存在するディレクトリ上に「A.service.wants」ディレクトリを作成し、このディレクトリ内にB.serviceへのシンボリックリンクを作成。
Requires	依存	強制力の有る依存関係。 Systemdはプロセスの同時起動を試み、依存先の起動に失敗した場合、依存元は起動しない。 ■「AはBに依存する」の定義方法 Wantsと同様の定義方法。A.serviceファイル内に記載する場合の設定項目は「Requires=B.service」となる。また、シンボリックリンクを利用する場合、作成するディレクトリ名は「A.service.requires」となる。
Conflict	依存	競合する関係。 Systemdはこの関係が定義されたプロセスは同時起動しない。 ■「AとBは競合する」の定義方法 A.service ------------------------------------------- [Unit] conflicts=A.service --------------------------------------------------- ※ B.serviceに「conflicts=A.service」と設定しても良い。
After	起動順	自身よりも前に起動するプロセスを定義。 ■ 「Aよりも前にBを起動する」の定義方法 A.service ------------------------------------------- [Unit] After=B.service --------------------------------------------------- ※ ”B.serviceより後に自分を起動してね”という設定
Before	起動順	自身よりも後に起動するプロセスを定義。 ■ 「Aの後にBを起動する」の定義方法 A.service ------------------------------------------- [Unit] Before=B.service --------------------------------------------------- ※ ”自分よりも後にBserviceを起動してね”という設定

複数のUnitをまとめる「target」Unit

targetと呼ばれる種類のUnitを利用することで複数のUnitをグルーピングすることができる。
targetは他Unitとの関係を保持し、複数のUnitをとりまとめる。例えばネットワーク関連のUnitをとりまとめたnetwork.targetや、従来のrc.sysinitに相当する処理をとりまとめたsysinit.target等が存在する。targetを利用することで、Unit同士の依存や起動順定義が楽に行うことができる。

例えばsysinit.targetの場合、targetで取りまとめられているUnitはsysinit.target自身やsysinit.target.wantsディレクトリに保存されている。

$ pwd
/usr/lib/systemd/system

$ cat sysinit.target
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

[Unit]
Description=System Initialization
Documentation=man:systemd.special(7)
Conflicts=emergency.service emergency.target
Wants=local-fs.target swap.target
After=local-fs.target swap.target emergency.service emergency.target
RefuseManualStart=yes

$ ls -l sysinit.target.wants/
合計 0
lrwxrwxrwx. 1 root root 20  6月 16 22:40 cryptsetup.target -> ../cryptsetup.target
lrwxrwxrwx. 1 root root 22  6月 16 22:40 dev-hugepages.mount -> ../dev-hugepages.mount
lrwxrwxrwx. 1 root root 19  6月 16 22:40 dev-mqueue.mount -> ../dev-mqueue.mount
lrwxrwxrwx. 1 root root 30  6月 16 22:42 plymouth-read-write.service -> ../plymouth-read-write.service
lrwxrwxrwx. 1 root root 25  6月 16 22:42 plymouth-start.service -> ../plymouth-start.service
lrwxrwxrwx. 1 root root 36  6月 16 22:40 proc-sys-fs-binfmt_misc.automount -> ../proc-sys-fs-binfmt_misc.automount
lrwxrwxrwx. 1 root root 32  6月 16 22:40 sys-fs-fuse-connections.mount -> ../sys-fs-fuse-connections.mount
lrwxrwxrwx. 1 root root 26  6月 16 22:40 sys-kernel-config.mount -> ../sys-kernel-config.mount
lrwxrwxrwx. 1 root root 25  6月 16 22:40 sys-kernel-debug.mount -> ../sys-kernel-debug.mount
lrwxrwxrwx. 1 root root 36  6月 16 22:40 systemd-ask-password-console.path -> ../systemd-ask-password-console.path
lrwxrwxrwx. 1 root root 25  6月 16 22:40 systemd-binfmt.service -> ../systemd-binfmt.service
lrwxrwxrwx. 1 root root 32  6月 16 22:40 systemd-journal-flush.service -> ../systemd-journal-flush.service
lrwxrwxrwx. 1 root root 27  6月 16 22:40 systemd-journald.service -> ../systemd-journald.service
lrwxrwxrwx. 1 root root 31  6月 16 22:40 systemd-modules-load.service -> ../systemd-modules-load.service
lrwxrwxrwx. 1 root root 35  6月 16 22:40 systemd-random-seed-load.service -> ../systemd-random-seed-load.service
lrwxrwxrwx. 1 root root 25  6月 16 22:40 systemd-sysctl.service -> ../systemd-sysctl.service
lrwxrwxrwx. 1 root root 37  6月 16 22:40 systemd-tmpfiles-setup-dev.service -> ../systemd-tmpfiles-setup-dev.service
lrwxrwxrwx. 1 root root 33  6月 16 22:40 systemd-tmpfiles-setup.service -> ../systemd-tmpfiles-setup.service
lrwxrwxrwx. 1 root root 31  6月 16 22:40 systemd-udev-trigger.service -> ../systemd-udev-trigger.service
lrwxrwxrwx. 1 root root 24  6月 16 22:40 systemd-udevd.service -> ../systemd-udevd.service
lrwxrwxrwx. 1 root root 33  6月 16 22:40 systemd-vconsole-setup.service -> ../systemd-vconsole-setup.service

例えばsysinit.targetファイルはAfter=local-fs.target swap.target emergency.service emergency.targetといった設定になっている。local-fs.targetとswap.targetはwants指定しているため、”同時起動”対象としてSystemdに認識されるが、emergency.serviceとemergency.targetは起動順の設定（After）のみとなっており、依存（Wants、Requires）の設定は行われていない。

これは、sysinit.targetの起動に伴ってemergency.serviceやemergency.targetの起動は行わない事を指しているが、emergency.service、emergency.targetが起動対象となった場合、これらのtarget/serviceはsysinit.targetよりも前に起動されるべきという関係を定義している。

Systemdにおけるランレベルの扱いと「default.target」

Unitの概念を理解した所で、Systemdにおけるランレベルの扱いを説明する。

ランレベルをUnitとして表現する

Systemdでは全てがUnit上で表現されるため、従来のランレベルというプロセスの管理体系は存在しない。Systemdではランレベルに相当する機能を先述のtarget Unitを利用して表現している。

ランレベルの目的は、ランレベル別に定義された状態でシステムを起動するために必要となるプロセスを管理することにあり、init/Upstartでは、/etc/rc.d/rc[runlevel].dにランレベルに応じたプロセス群を定義することでこれを実現していた。
Systemdでは、これらのプロセスをtargetとしてグルーピングすることでランレベルと同様のプロセス管理を実現している（※）。例えば、従来のランレベル3（マルチユーザ・コンソールログインのみ）に必要となるプロセス群はmulti-user.targetとして定義されている。

※ 従来のランレベルは0 – 6の7種類のみ定義されていたのに対し、targetは好きなだけ定義できるため、より柔軟になったと言える。

システムの起動後状態を表す定義済targetは以下の通りである。

target名	内容	従来のランレベル (RedHat)
poweroff.target	システム停止	0
rescue.target	シングルユーザモード	1
multi-user.target	マルチユーザモード（コンソールログイン）	3
graphical.target	マルチユーザ＋GUI	5
reboot.target	再起動	6
emergency.target	緊急シェル rescue.targetよりも起動対象が少ないルートファイルシステムですらマウントできない場合などに利用	無し

また、互換性？のために従来のランレベルを意図した名称のtargetが定義されている。ただし、これらのtargetは上表のtargetへのシンボリックリンクとなっている。

$ pwd
/usr/lib/systemd/system

$ ll runlevel*.target
lrwxrwxrwx. 1 root root 15  6月 16 22:40 runlevel0.target -> poweroff.target
lrwxrwxrwx. 1 root root 13  6月 16 22:40 runlevel1.target -> rescue.target
lrwxrwxrwx. 1 root root 17  6月 16 22:40 runlevel2.target -> multi-user.target
lrwxrwxrwx. 1 root root 17  6月 16 22:40 runlevel3.target -> multi-user.target
lrwxrwxrwx. 1 root root 17  6月 16 22:40 runlevel4.target -> multi-user.target
lrwxrwxrwx. 1 root root 16  6月 16 22:40 runlevel5.target -> graphical.target
lrwxrwxrwx. 1 root root 13  6月 16 22:40 runlevel6.target -> reboot.target

default.targetを切り替えてランレベルを制御する

詳細は後述するが、Systemdにおける起動の基点となるUnitはdefault.targetである。Systemdは起動の後、このdefault.targetを探し、default.targetに記載されたUnit間の関係を元に最終的に起動するプロセス群を把握する。

default.target自身は特に処理を持たず、任意のUnitへのシンボリックリンクとして利用するのが一般的だ。このシンボリックのリンク先を上述の起動後状態を表す.targetとすることで従来のランレベル変更に相当する操作を行う事ができる。

$ # multi-userモード（従来のRunlevel3）で起動する場合の設定
$ # default.targetのリンク先をmulti-user.targetとする
$ ll /etc/systemd/system/default.target
lrwxrwxrwx. 1 root root 37  6月 21 17:09 /etc/systemd/system/default.target -> /lib/systemd/system/multi-user.target

init、Systemdによるシステム起動の比較

次に従来のinitによるシステム起動とSystemdの起動を比較してみよう。
温故知新ということで、従来のinit起動後の動作について解説しておく。従来のinitの動作がSystemdではどのような振る舞いに置き換わるのか確認してみよう。

init/Upstartの起動プロセス

initは「1．init起動」した後、「2．/etc/inittabを読み込み」、「3．rc.sysinitを実行」する。次に「4．inittabに記載されたランレベルに応じて、/etc/rc.d/rc[Runlevel].d内のスクリプトを実行」していく。各プロセスの起動が終了した後、ターミナルからの接続プロセスである「5．ログイン受付プロセスを起動」（mingettyなど）し、起動プロセスを完了する。まとめると以下のようになる。

この起動プロセスはUpstartの場合であってもさほど変わりは無い。
initによる起動では、プロセスの起動順序を/etc/rc.d/rc[runlevel].d内のシンボリックリンク名によって制御していた。例えば/etc/rc.d/rc3.dは以下のようになっている。

$ pwd
/etc/rc.d/rc3.d

$ ls -l
lrwxrwxrwx. 1 root root 16  4月  8 20:02 2014 K01smartd -> ../init.d/smartd
lrwxrwxrwx. 1 root root 17  4月  8 20:00 2014 K02oddjobd -> ../init.d/oddjobd
lrwxrwxrwx. 1 root root 17  4月  8 20:03 2014 K05wdaemon -> ../init.d/wdaemon
lrwxrwxrwx. 1 root root 16  4月  8 20:02 2014 K10psacct -> ../init.d/psacct
lrwxrwxrwx. 1 root root 19  4月  8 20:00 2014 K10saslauthd -> ../init.d/saslauthd
lrwxrwxrwx. 1 root root 22  4月  8 20:00 2014 K15htcacheclean -> ../init.d/htcacheclean
# ============================= 一部抜粋 =============================
lrwxrwxrwx. 1 root root 17  4月  8 20:01 2014 S01sysstat -> ../init.d/sysstat
lrwxrwxrwx. 1 root root 22  4月  8 20:01 2014 S02lvm2-monitor -> ../init.d/lvm2-monitor
lrwxrwxrwx. 1 root root 19  4月  8 20:00 2014 S08ip6tables -> ../init.d/ip6tables
lrwxrwxrwx. 1 root root 18  4月  8 19:58 2014 S08iptables -> ../init.d/iptables
lrwxrwxrwx. 1 root root 17  4月  8 19:58 2014 S10network -> ../init.d/network
lrwxrwxrwx. 1 root root 16  4月  8 20:02 2014 S11auditd -> ../init.d/auditd
lrwxrwxrwx. 1 root root 21  4月  8 19:55 2014 S11portreserve -> ../init.d/portreserve
# ============================= 一部抜粋 =============================

ディレクトリ内の個々のファイルは、/etc/rc.d/init.d内にある起動スクリプトへのシンボリックリンクとなっている。また、シンボリックリンクの名称が「Kxxプロセス名」「Sxxプロセス名」となっており、この「xx」の部分で起動・停止順を定義している。（Kxxは該当ランレベルで停止するプロセス、Sxxは起動するプロセス）
先述したSystemdにおける、依存といった区分けは無く、単純に起動順のみが定義された状態である。

Systemdの起動プロセス

Systemdの起動プロセスは以下の通りである。

initと比較するとプロセスの起動順をSystemd自体が決定していることが分かる。initの場合は/etc/rc.d/rc[runlevel].dディレクトリのシンボリックリンクの命名規則によって起動順を指定していたが、Systemdでは、Unitに定義されたUnit間の関係を元にSystemd側で起動順を決定する。
また、全てがUnitによって定義されているため、initのようなrc.sysinitやランレベルといった区分けは無く、システム起動に必要な処理を分け隔て無く管理できていることが分かる。

起動プロセスのゴール地点（default.target）からUnit間の関係を遡ることによって、システム起動に必要となる全てのUnitをSystemd側が把握することで、最適なシステム起動順によるシステム起動を実現している事が分かる。