systemctl enableしたのに自動起動しない原因と確認手順
このページの目的
「enableされていない」のか、「enableはされているが起動時に失敗・スキップされた」のかを分けます。最終的なゴールは、再起動時にどのtargetから呼ばれ、どこで起動が止まったかを確認することです。
最初にやること
最初に systemctl is-enabled で登録状態を確認し、次に journalctl -b -u で現在の起動時ログを確認します。登録と実行結果を混同しないことが重要です。
このページの対象：このページは「手動起動はできるが、再起動後に自動起動しない」場合が中心です。手動起動そのものが失敗する場合は、systemdサービスが起動しないガイドを先に確認してください。
systemd Unitを適用前に確認
Unitファイルを貼り付けて、WantedBy、依存関係、Restart、実行ユーザーなどの注意点を確認できます。
最初に登録と起動結果を分ける
enableは今すぐ起動する操作ではありません。まず次の2点を別々に確認します。
- 自動起動へ登録されているか：
systemctl is-enabledと作成されたリンクを確認 - 起動時に実際に動いたか：
journalctl -b -uで失敗・条件不成立・依存関係を確認
systemctl is-enabled example.service
systemctl status example.service --no-pager
journalctl -b -u example.service --no-pager
よくある表示・症状から原因を絞る
表示された文言は原因そのものではなく、確認範囲を絞る手掛かりです。「考えられる原因」と「最初の確認方法」を対応させて確認します。
| エラー・症状 | 考えられる原因 | 最初の確認方法 |
|---|---|---|
disabled | enableされておらず、自動起動用のリンクが作成されていない | systemctl is-enabled と enable実行結果を確認 |
static | [Install]がなく、単独では通常のenable対象にならないUnit | systemctl cat と、そのUnitを起動する依存元を確認 |
indirect | Also=や別名Unitを経由して有効化する構成 | systemctl cat とUnitのシンボリックリンクを確認 |
The unit files have no installation config | [Install]、WantedBy=、RequiredBy=、Alias=などの有効化設定がない | Unitの[Install]と設計上の起動方法を確認 |
Failed to enable unit: Unit file ... does not exist | Unit名の誤り、配置先違い、またはdaemon-reload未実施 | systemctl list-unit-files とUnit配置先を確認 |
Condition ... was not met | Condition指定の判定がfalseになり、起動がスキップされた | systemctl show -p Conditions -p ConditionResult で条件判定を確認 |
Dependency failed for ... | 依存先Unit、mount、networkなどが起動に失敗した | journalctl -b と systemctl list-dependencies を確認 |
原因を切り分ける確認手順
enable状態を確認する
systemctl is-enabled example.service systemctl list-unit-files example.serviceenabled以外なら、Unitに[Install]があるか、正しいUnit名を指定しているか確認します。作成されたリンクを確認する
systemctl show -p FragmentPath example.service find /etc/systemd/system -type l -lname '*example.service' -ls想定するtarget配下にリンクが作られているか確認します。テンプレートUnitやaliasを使う場合は対象名にも注意します。
起動時の失敗ログを確認する
journalctl -b -u example.service --no-pager systemctl status example.service --no-pager-bで現在の起動以降のログに絞り、依存先、権限、実行パス、環境変数などを確認します。条件・依存関係を確認する
systemctl show example.service -p Wants -p Requires -p After -p ConditionResult systemd-analyze verify /etc/systemd/system/example.serviceConditionPathExists=などの条件が不成立だと、失敗ではなくスキップされることがあります。再起動前に起動経路を試す
sudo systemctl daemon-reload sudo systemctl restart example.service systemctl status example.service --no-pager手動起動できても、起動時だけ利用できないネットワーク、マウント、秘密情報、名前解決などがないか確認します。
確認結果から次の対応を決める
| 結果 | 次の対応 |
|---|---|
| disabled / static | [Install]とWantedBy=、Unit名を確認します。 |
| enabledだがinactive | journalctl -b -uで起動時ログとConditionを確認します。 |
| dependency failed | 依存先Unit、マウント、ネットワークの状態を先に確認します。 |
| 手動起動は成功する | 起動順序、環境変数、起動時に未準備のリソースを疑います。 |
この症状で多い原因
systemctl enableと--nowを混同している[Install]またはWantedBy=がない・不適切- Unit名やテンプレートインスタンス名が違う
- Condition指定で起動がスキップされる
- 依存先のマウント・ネットワーク・サービスが失敗している
- 起動時だけPATHや環境変数、秘密情報が不足する
再発防止
sudo systemd-analyze verify /etc/systemd/system/example.service
sudo systemctl daemon-reload
sudo systemctl enable --now example.service
systemctl is-enabled example.service
systemctl is-active example.service
本番再起動で初めて確認するのではなく、Unit構文、enable状態、依存先、起動ログを事前に確認してください。
WantedBy=multi-user.targetの詳しい仕組みと、After・Wants・Requiresの違いもあわせて確認できます。