「systemctl enableしたサービスが、再起動後に想定と違う順番で起動する」
サービスの起動順序が原因のトラブルは、Linuxサーバー運用の現場でよく起きるつまずきのひとつです。
この記事では、RHEL 9系／Rocky Linux 9を想定環境として、systemdユニットファイルの依存関係ディレクティブ（After・Requires・Wants・WantedBy）の意味と使い分けを解説します。ユニットファイルの書き方から、systemctl list-dependenciesを使った確認手順まで説明します。
この記事のポイント
・After/Beforeは起動「順序」だけを指定する（失敗しても連鎖しない）
・Requiresは依存先が止まると自分も止まる・Wantsは止まっても続行する
・WantedByはsystemctl enableで作られるリンクの向き先を指定する
・systemctl list-dependenciesで依存ツリーを確認できる
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
サービスの起動順序が重要な理由
systemdは複数のサービスを並列起動します。依存関係の指定がないと、起動順序は保証されません。典型的なトラブルは、DBサーバーへの接続が必要なWebアプリが先に起動してしまい、「データベースに接続できない」というエラーを出して停止するケースです。
ユニットファイルに依存関係を正しく設定することで、「DBが起動を完了してからWebアプリを起動する」という順序を確実に制御できます。本番サーバーの安定運用において重要な設定です。
After・Beforeで起動「順序」を指定する
Afterディレクティブは「指定したユニットが起動処理を完了した後にこのサービスを起動する」という、起動順序のみを制御するディレクティブです。依存先が起動に失敗した場合の動作（自分も停止するかどうか）はAfterだけでは制御できません。それはRequires・Wantsの役割です。
1. Afterを書く
# /etc/systemd/system/myapp.service の [Unit] セクション [Unit] Description=My Web Application After=mariadb.service network.target
「mariadbとnetwork.targetの両方が起動した後にmyappを起動する」という設定です。
2. BeforeはAfterの逆向き
BeforeはAfterの逆で「自分が指定ユニットより先に起動する」という意味です。相手のユニットファイルにAfter=を書くことと実質的に同じになるため、自分が管理するサービスのユニットファイルではAfterで書いた方が分かりやすい場合がほとんどです。
Requires・Wantsで依存関係の「強度」を決める
Afterは起動順序だけを制御します。依存先が失敗した時にどう動くかは、RequiresまたはWantsで設定します。3. Requires：依存先が止まると自分も止まる
[Unit] Description=My Web Application After=mariadb.service Requires=mariadb.service
「DBなしでは動作しない」サービスに適しています。
4. Wants：依存先が止まっても自分は続行する
[Unit] Description=My Web Application After=memcached.service Wants=memcached.service
キャッシュサーバーのように「あれば使うが、なくても動く」コンポーネントに適しています。
WantedByとsystemctl enableの関係
[Install]セクションのWantedByは、systemctl enableコマンドが何をするかを決めます。# /etc/systemd/system/myapp.service の [Install] セクション [Install] WantedBy=multi-user.target
systemctl enable myappを実行すると、/etc/systemd/system/multi-user.target.wants/myapp.serviceというシンボリックリンクが作成されます。multi-user.targetは通常の起動状態（ランレベル3相当）を表します。これにより、次回起動時にmulti-user.targetが有効になるとmyappが自動的に起動するようになります。
systemdのサービス管理を体系的に学びたい場合は、Linuxサーバー構築セミナーでも実務設計を含めて詳しく扱っています。
systemctl list-dependenciesで依存ツリーを確認する
ユニットの依存関係は以下のコマンドで視覚的に確認できます。systemd-analyze で起動時間計測と組み合わせると、ボトルネックの特定もしやすくなります。5. 依存ツリーを表示する
# サービスの依存ツリーを確認する systemctl list-dependencies myapp.service
myapp.service * ├─mariadb.service * ├─network.target * │ └─... * └─basic.target └─...
6. 逆方向の依存を確認する
# このサービスに依存しているユニットを確認する systemctl list-dependencies --reverse myapp.service
BindsTo・PartOfでさらに強い連鎖を設定する
RequiresよりさらにきついBindsToは、依存先が再起動・リロードされた場合にも自分も再起動されます。[Unit] Description=My Database Worker # mariadb が再起動されたら自分も再起動される BindsTo=mariadb.service After=mariadb.service
よくあるハマりポイントとトラブルシュート
「Afterだけ書いてRequiresを入れていない」ケース
Afterだけ書いた場合、起動順序は守られますが依存先が起動に失敗しても自分は起動を試みます。DBなしでは起動して欲しくない場合はRequires=の追加が必要です。「daemon-reloadを忘れた」ケース
ユニットファイルを変更した後、systemctl daemon-reloadを実行しないと変更が反映されません。ファイルを編集したら必ず実行します。# ファイル変更後は必ず再読み込みする sudo systemctl daemon-reload sudo systemctl restart myapp.service
「systemctl enableしたのに自動起動しない」ケース
[Install]セクションにWantedBy=multi-user.targetがないユニットをenableしても何も起きません。【重要】[Install]セクションを追加した後は、systemctl daemon-reloadしてからsystemctl enableし直す必要があります。
# [Install] セクションを追加してから enable し直す sudo systemctl daemon-reload sudo systemctl enable --now myapp.service
「起動に失敗した依存先のサービスを確認したい」場合
依存関係の問題でサービスがfailedになった場合は、journalctlでログを確認します。# サービスのログで失敗原因を確認する journalctl -u myapp.service -n 50 --no-pager # 依存先のサービスが起動しているかを確認する systemctl status mariadb.service
本記事のまとめ
After・Requires・Wants・WantedByの役割を整理します。| ディレクティブ | セクション | 役割 | 依存先が失敗した場合 |
|---|---|---|---|
| After= | [Unit] | 指定ユニットの後に起動する（順序のみ） | 自分は起動を試みる |
| Before= | [Unit] | 指定ユニットより先に起動する（順序のみ） | 自分は起動を試みる |
| Requires= | [Unit] | 強い依存。失敗・停止が連鎖する | 自分も起動しない・停止する |
| Wants= | [Unit] | 弱い依存。失敗しても自分は続行する | 自分は起動を続ける |
| BindsTo= | [Unit] | 最強の依存。再起動も連鎖する | 自分も停止・再起動される |
| WantedBy= | [Install] | enableで作られるリンク先のターゲット | 自動起動の設定に影響する |
・「AのあとにBを起動したい」→ BのユニットにAfter=A.service
・「AがないとBは動かない」→ After=A.service と Requires=A.service を両方書く
・「Aがあれば使うが、なくてもBは動く」→ After=A.service と Wants=A.service を書く
・「次回起動時に自動起動させたい」→ [Install]セクションにWantedBy=multi-user.target
Afterだけ・Requiresだけを書くミスが多いため、「順序（After）」と「依存強度（Requires/Wants）」を別々に意識して設計するようにしましょう。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、ハンズオン形式のLinuxサーバー構築セミナーを開催しています。systemdの実務設計を含め、RHEL10対応・少人数制で体系的に学べます。＞＞ セミナーの詳細はこちら
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
- 前のページへ：AlmaLinux自宅サーバーのトラブル対応集｜ログ解析と復旧手順
- この記事の属するカテゴリ：Linuxtipsへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます