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 を持ち、以降に動くすべてのプロセスの大もとの親になる、いわばシステムの司令塔です。かつての SysVinit という仕組みでは、サービスを起動スクリプトで順番に1つずつ立ち上げていましたが、systemd は依存関係を解きほぐしながら、起動できるものから並列に立ち上げます。これが、現代のLinuxの起動が速い理由のひとつです。サービスの起動・停止・自動起動の管理を、ばらばらのツールではなく systemctl という単一のコマンドで一貫して行えるのも大きな特徴です。
unit — 管理対象を一つの単位で扱う
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/ に置かれます。
target — ランレベルの後継、まとまった起動状態
individual な unit をいくつも束ねて、「システム全体のある状態」を表すのが .target という特別な unit です。これはかつての SysVinit における『ランレベル』に相当する概念です。よく使うものを挙げると、multi-user.target は複数ユーザがネットワーク経由で使える文字コンソール環境(かつてのランレベル3に相当)、graphical.target はそれに加えてGUIのログイン画面まで立ち上がった状態(ランレベル5に相当)、rescue.target は最小限のサービスだけで立ち上げる復旧用の状態、です。システムが起動時に最終的に目指す target は『既定のターゲット』として設定されており、systemctl get-default で確認、systemctl set-default graphical.target のように変更できます。一時的に状態を切り替えたいときは systemctl isolate multi-user.target のように指定します。
systemctl の基本操作
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)が必要です。
ログは journalctl で追う
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 の広い機能の中で迷わずに済みます。