見出し画像

systemd の依存関係、設定ミスで起動順にズレ『サーバOSの話②』

nobu.ai.design

systemd に慣れていない初学者がよく踏む落とし穴。
サービス自体の設定は正しいのに、
“起動順がズレている”ためにサービスが正常に動かない。
特に Web＋DB、アプリ＋ネットワーク、ストレージマウントなどの組み合わせで多発する。

起動順は目に見えないため、原因特定が遅れやすい。
systemd を使う以上、避けて通れないポイントだ。

ひと言まとめ

systemd は依存関係がすべて。
正しく書かれていないと、サービスが想定外の順番で起動する。

症状（あるある）

  • サービスは“起動した”と出るが、実際は動いていない

  • Webアプリが DB につながらずエラー

  • NFS をマウントできず、アプリがコケる

  • ネットワークが上がる前にサービスが起動して失敗

  • 再起動したときだけ動かない（手動起動は成功）

  • systemctl status では正常に見えるが、ログに Connection refused

原因と仕組み（なぜ起きる？）

  • Unitファイルの After / Wants / Requires の理解不足

  • “ネットワークが上がった後に起動すべきサービス”に
    　After=network-online.target を書き忘れ

  • DB 依存アプリに Requires= を書かず、先に起動して失敗

  • mount系ユニットの依存順が不整合で、再起動時だけエラー

  • Unitファイル編集後に daemon-reload を実施していない

  • systemd は parallel（並列）起動のため、暗黙の依存は成立しない

図：起動順ズレの典型例（アプリが DB より先に起動して失敗）

起動順（誤）：
[App] → [DB]
    ↓      ↑
  DB未稼働で接続失敗

起動順（正）：
[DB] → [App]

切り分け（最短コース）

  1. journalctl で起動直後のログを確認

    1. journalctl -u app.service -b

  2. 依存関係の確認

    1. systemctl show app.service | grep -E "After|Requires|Wants"

  3. ネットワーク系サービスの起動タイミング確認

    1. systemctl status network-online.target

  4. 手動起動で成功するか
    → 手動OK・再起動NGなら“起動順”が原因

  5. Unitファイルの編集有無確認
    → /etc/systemd/system/*.service を確認
    　　Vendor提供の unit を上書きしていないかチェック

今すぐ効く対処（テンプレ）

  • 依存関係を正しく追記
    例：アプリが DB に依存する場合
    /etc/systemd/system/app.service

    1. [Unit] After=network-online.target mariadb.service Requires=mariadb.service

  • ネットワーク依存サービスは必ず network-online.target を使用

    1. systemctl enable NetworkManager-wait-online.service

  • Unit 変更後は必ず

    1. systemctl daemon-reload

  • 再起動して起動順が期待通りか確認

    1. systemctl reboot

恒久対策／再発防止チェックリスト

  • 依存関係（Requires/After）を明文化したテンプレを用意

  • ネットワーク依存は network-online.target を徹底

  • Unitファイル編集後の daemon-reload を標準手順に

  • DB・ストレージなど基盤サービスは先に起動させる

  • mountユニットは RequiresMountsFor= を活用

  • 再起動テストを必ず実施（手動起動だけで判断しない）

  • Vendor Unit 上書きは避け、カスタム Unit に分離

  • systemd-analyze で起動シーケンスを定期確認

落とし穴（やりがちミス）

  • “After=network.target” を書けばOKと思い込む（不十分）

  • App → DB の順で起動してしまい、深夜バッチが毎回失敗

  • mount失敗が依存順のせいだと気づかず永遠に調査

  • vendor提供の unit を直接書き換えてアップデートで消える

  • “手動起動OKだから大丈夫”と思って本番で落ちる

変更後の確認ポイント

  • 依存するサービスが正常に起動している

  • journalctl に再発ログが出ていない

  • 再起動後もアプリが安定稼働

  • systemd-analyze で起動順が期待通り

  • Unit ファイルの整合性が取れている

まとめ（行動指針）

systemd の本質は “依存関係の明確化”。
ここをミスると OSブート時の不具合は永遠に解決しない。

依存を書く → 並列起動を理解する → 再起動で確認。
これだけで systemd 起因のトラブルは劇的に減る。

いいなと思ったら応援しよう！