systemd と unit / target
systemd は現代の多くのディストリビューションで採用されている、最初のユーザ空間プロセス(PID 1)です。管理対象を「unit」という単位で扱い、サービスは .service、マウントは .mount、まとまった起動状態は .target として表現します。target はかつてのランレベルに相当し、たとえば multi-user.target は文字コンソール環境、graphical.target はGUI環境を意味します。systemctl で各unitの状態確認・起動・停止・自動起動の有効化を一貫して行えます。依存関係を解決しながらサービスを並列起動するため、起動が速いのも特徴です。
Linuxが起動して最初に立ち上がるユーザ空間プロセス、いわば一番手は init と呼ばれる。現在の多くのディストリビューション(MiracleLinuxを含むRHEL系や、Ubuntuなど)では systemd がその役を担う。
systemd は必ず PID 1 を持ち、以降に動くすべてのプロセスの大もとの親になる。いわばシステムの司令塔だ。
現代のLinuxが昔より起動が速くなった理由も、ここにある。かつての SysVinit という仕組みでは、サービスを起動スクリプトで順番に1つずつ立ち上げていた。
一方 systemd は依存関係を解きほぐしながら、起動できるものから並列に立ち上げる。この並列化が、起動が速い理由のひとつだ。
サービスの起動・停止・自動起動の管理を、ばらばらのツールではなく systemctl という単一のコマンドで一貫して行えるのも大きな特徴である。
🧩 サービスもマウントも同じ単位で扱う
systemd の世界を理解する鍵は unit という考え方だ。systemd は、起動・管理するあらゆる対象を unit という統一された単位で扱う。
unit にはいくつか種類があり、拡張子で見分けられる。代表的なのは、デーモン(常駐サービス)を表す .service だ。たとえばWebサーバなら httpd.service、SSHサーバなら sshd.service、といった具合である。
ほかにも、ファイルシステムのマウントを表す .mount、ある時刻やイベントでサービスを起動するタイマーを表す .timer、デバイスを表す .device などがある。
性質のまったく違うものを同じ仕組みで扱えるのは、「サービスもマウントもタイマーも、すべて unit という同じ土俵で扱う」という統一感のおかげだ。これが systemd を見通しよくしている。
各 unit の設定は、システム提供分は /usr/lib/systemd/system/ に、管理者が上書きする分は /etc/systemd/system/ に置かれる。
🎚 文字コンソールまでか、GUIまでか
個々の unit をいくつも束ねて、「システム全体のある状態」を表すのが .target という特別な unit だ。これはかつての SysVinit における「ランレベル」に相当する概念である。
よく使うものを挙げる。multi-user.target は複数ユーザがネットワーク経由で使える文字コンソール環境(かつてのランレベル3に相当)、graphical.target はそれに加えてGUIのログイン画面まで立ち上がった状態(ランレベル5に相当)、rescue.target は最小限のサービスだけで立ち上げる復旧用の状態だ。
システムが起動時に最終的にどの状態を目指すかは、「既定のターゲット」として設定されている。systemctl get-default で確認、systemctl set-default graphical.target のように変更できる。
一時的に状態を切り替えたいときは systemctl isolate multi-user.target のように指定する。
⚙ 今すぐ起動と次回も自動起動は別物
systemd の操作の中心は systemctl コマンドで、最初の引数(サブコマンド)で何をするかを切り替える。
あるサービスの状態を見るには systemctl status sshd、起動は systemctl start sshd、停止は systemctl stop sshd、設定変更を反映する再起動は systemctl restart sshd だ。
ここで多くの人が混同する。「今すぐ起動する」ことと「次回以降も自動起動する」ことは、別の操作なのだ。
電源投入時に自動で立ち上がるようにするには systemctl enable sshd、自動起動をやめるには systemctl disable sshd を使う。enable は「次回の起動から有効」なので、今すぐかつ次回からも、という場合は systemctl enable --now sshd とまとめられる。
いま動いているサービスを一覧するには systemctl list-units --type=service が便利だ。これらの操作はシステム全体に影響するため、多くは管理者権限(sudo)が必要になる。
🔍 サービスが起動に失敗したら
systemd 環境では、各サービスが出すログは journald という仕組みが一元的に収集している。それを読むコマンドが journalctl だ。
特定のサービスのログだけ見たいなら journalctl -u sshd、今回の起動以降のログだけなら journalctl -b、新しい行を追いかけ続けるなら journalctl -f を使う。
サービスが起動に失敗したときの定番の動きはこうだ。まず systemctl status で概況を見て、続けて journalctl -u サービス名 で詳しいエラーを追う。この流れを手になじませておくと、つまずいたときに迷わない。
⚠ 再起動したらサービスが消える理由
よくある誤解は、start と enable を同じものと思ってしまうことだ。start しただけでは再起動後に立ち上がらないし、enable しただけでは今は動かない。
この違いを押さえておかないと、「サーバを再起動したらサービスが消えた」という事故につながる。
もうひとつ、systemd を SysVinit と同じ感覚で起動スクリプトの順番をいじって制御しようとするのも誤りだ。systemd では順序は unit ファイルの依存関係(After= や Requires= など)で記述する。
実務では、新しく入れたサービスを enable --now で有効化し、status と journalctl で正常稼働を確認する、という一連の流れが日常作業の基本になる。
サービス・マウント・タイマーといった対象を unit という共通の単位で捉え、状態のまとまりを target で扱い、操作は systemctl に、ログは journalctl に集約する。この見取り図さえ持っておけば、systemd の広い機能の中で迷わずに済む。