systemd（システムディー）は、現代の主要なLinuxディストリビューションが標準採用しているinit（PID 1）およびサービス管理スイートです。2010年にRed Hat社のLennart Poetterring（レナート・ペッタリング）らによって開発が開始され、従来のSysVinitやUpstartに代わる存在として急速に普及しました。並列起動による高速ブート、依存関係に基づくサービス管理、ジャーナル方式の統合ロギング、cgroupsとの密接な統合など、システム全体を統括する数多くの機能を提供します。Ubuntu、Debian、Fedora、RHEL、CentOS、Arch Linuxなど主要ディストリビューションが採用し、Linuxシステム運用の事実上の標準となっています。
この記事の目次
- systemdを構成する3本柱の機能群
- サービス起動から管理までの基本フロー
- systemd運用前に押さえるチェック項目
- 従来initとsystemdの設計思想の違い
- まとめ
systemdを構成する3本柱の機能群
systemdの中核はUnitと呼ばれる抽象化された管理単位です。serviceはデーモンプロセス、socketはネットワークやIPCのリッスン、mountはファイルシステムのマウント、timerは定期実行、targetは複数Unitの集合を表すといった具合に、システム上のあらゆるリソースを統一的な書式で記述します。Unitファイルは/etc/systemd/system/や/lib/systemd/system/に配置され、systemctl start や systemctl enable といった一貫したコマンドで操作できます。これにより従来バラバラだった起動スクリプトや管理手順が大幅に整理されました。
ロギング基盤のjournald（ジャーナルディー）は、各サービスの標準出力や標準エラー出力、syslog経由のログを自動的に取り込み、バイナリ形式のジャーナルファイルに構造化して保存します。journalctlコマンドでサービス単位、優先度、時刻範囲、ブートIDなど豊富な絞り込みが可能で、トラブルシュート時の調査速度を劇的に向上させます。さらにlogindがユーザーセッションを管理し、timer Unitがcronの代替として動作するなど、systemdは単なるinitを超えてシステム全体を統括する包括的なフレームワークとして機能しています。
サービス起動から管理までの基本フロー
新しいサービスをsystemdで管理するための基本手順は明快で、対象アプリケーションのUnitファイルを記述するところから始まります。typical な service Unit には [Unit] セクションに依存関係、[Service] セクションに ExecStart や Restart 等の起動方法、[Install] セクションに WantedBy 等の有効化先を記述します。/etc/systemd/system/myapp.service に保存したのち、systemctl daemon-reload で systemd に新規Unitを認識させます。
起動と自動化の制御も統一されています。systemctl start myapp で即時起動、systemctl enable myapp で次回ブート以降の自動起動を有効化、systemctl restart や reload でプロセスを再始動できます。動作確認には systemctl status myapp で現在の状態と直近ログを参照し、より詳細な調査には journalctl -u myapp -f でリアルタイムにログを追跡します。Restart=on-failure と RestartSec= の組み合わせで自動復旧、Type=notify と sd_notify でアプリケーション側からの起動完了通知など、運用に必要な機能が一貫した形で提供されている点が大きな魅力です。
systemd運用前に押さえるチェック項目
systemdを本格運用する前に確認しておきたいのは、まずUnitファイルの基本構造とディレクトリ階層です。/lib/systemd/system にはパッケージが提供する標準Unitが置かれ、/etc/systemd/system にはサイト固有の設定やオーバーライドを配置するのが慣習です。同名ファイルがあると /etc が優先されるため、ディストリビューションの設定を残しつつ独自の調整を加える際は、systemctl edit を用いた drop-in 形式の上書きが推奨されます。
依存関係の表現も重要なポイントです。Afterは順序関係のみを定義し、Requiresは順序に加え強い依存（依存先が止まると自身も停止）を意味し、Wantsは弱い依存（依存先の失敗を許容）を表します。これらを取り違えると、ブート時に予期せぬサービス停止が発生するため正確な理解が欠かせません。さらにType=simple／forking／notify／oneshotの選択を誤ると、起動完了の判定がずれて後続サービスがタイミングよく起動しない問題が生じます。journalctl --boot や systemd-analyze blame、systemd-analyze critical-chain を活用してブート性能と依存関係を可視化することが、安定運用の第一歩となります。
従来initとsystemdの設計思想の違い
従来のSysVinitでは、/etc/init.d/以下のシェルスクリプトを順次実行する設計が採用されており、起動順序の制御はランレベル（0〜6）と /etc/rc?.d/ のシンボリックリンクの並び順で表現されていました。スクリプトは start／stop／restart 等の引数を解釈する必要があり、品質や挙動がスクリプトごとにバラつきがちで、依存解決やプロセス監視は別途daemontoolsやmonit等の外部ツールに頼る場面が多くありました。
対照的にsystemdは、Unitファイルという宣言的な記述に基づいて依存関係を解析し、可能な部分は並列で起動するアーキテクチャを採用しています。socket activationやD-Bus activationによる遅延起動も組み合わせて、ブート時間を大幅に短縮します。また、cgroups統合により各サービスが生成する子プロセスまで確実にトラッキングし、stop時に取り残しが発生しないようにします。一方でsystemdは機能範囲が広く「Unix哲学に反する」との批判もあり、軽量代替としてOpenRCやrunit、s6を採用するディストリビューションも存在します。とはいえ主要ディストリビューションでは事実上の標準として定着しており、Linuxエンジニアにとって必須の知識となっています。
まとめ
systemdは、initという小さな役割を遥かに超え、Linuxシステム全体のライフサイクル管理を担う包括的な基盤として機能しています。Unitによる宣言的な記述、journaldによる統合ロギング、cgroupsとの連携によるリソース管理は、現代のサーバー運用に欠かせない要素となりました。学習コストは小さくないものの、systemctlとjournalctlを使いこなせば運用効率は確実に向上します。Linuxを扱うすべてのエンジニアにとって、避けて通れない中核技術と言えるでしょう。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント