systemctl daemon-reloadはいつ必要？restart・reloadとの違い
systemctl daemon-reload は、systemdマネージャーにUnitファイルを読み直させ、依存関係ツリーを再構築させる操作です。Unitファイルやdrop-inを手動で作成・変更したあとに、変更内容をsystemdへ認識させるために使います。
このページで分かること
- daemon-reloadが必要な変更
- restart・reloadとの違い
- 変更後に何を確認するか
- Unitの構文を適用前に検証する方法
先に結論
Unit定義を変更したら、まず構文確認 → daemon-reload → 必要に応じてrestart/start → status確認の順に分けると安全です。
sudo systemd-analyze verify /etc/systemd/system/example.service
sudo systemctl daemon-reload
sudo systemctl restart example.service
systemctl status example.service --no-pager -l
変更前にUnitファイルを確認する
Unitを貼り付けて、ExecStart、依存関係、WantedBy、Restartなどの注意点を適用前に確認できます。
daemon-reloadはいつ必要か
代表例は、/etc/systemd/system/ 配下などのUnitファイルを手動で作成・編集したとき、drop-inを手動で変更したとき、Unitの依存関係や実行コマンドを変更したときです。daemon-reloadはUnit定義を読み直しますが、サービスプロセスそのものを自動で再起動する操作ではありません。
| 変更 | daemon-reload | その後 |
|---|---|---|
| UnitファイルのExecStart=を変更 | 必要 | restartで新しい定義を使って再起動 |
| After=/Wants=/Requires=を変更 | 必要 | 依存関係を確認して必要なUnitを再起動 |
| [Install]を変更 | enable/disableのやり直しを優先 | systemctl enable/disableは通常、リンク変更後にsystemdマネージャーの設定も再読込します。symlinkを手動変更した場合はdaemon-reloadも確認 |
| アプリ自身の設定ファイルだけ変更 | 通常は不要 | アプリが対応していればsystemctl reload、必要ならrestart |
注意：
daemon-reload と systemctl reload example.service は別物です。前者はsystemd側のUnit定義、後者は対応しているサービス自身へ設定再読込を要求します。daemon-reload・restart・reloadの違い
| コマンド | 対象 | 主な用途 |
|---|---|---|
systemctl daemon-reload | systemdマネージャー | Unitファイルを再読込し依存関係ツリーを再構築 |
systemctl restart example.service | サービス | 停止・起動して新しい実行状態へ切り替える |
systemctl reload example.service | サービス | サービス固有のreload処理を要求。通常は設定再読込が目的だが、具体的な動作と影響はサービス実装を確認 |
restart だけで「systemdがUnitファイル変更を必ず再読込してくれる」と決めつけず、Unit定義変更時はdaemon-reloadを明示して確認します。
安全な変更手順
sudo cp -a /etc/systemd/system/example.service /etc/systemd/system/example.service.bak
sudo editor /etc/systemd/system/example.service
sudo systemd-analyze verify /etc/systemd/system/example.service
sudo systemctl daemon-reload
systemctl cat example.service
systemctl show example.service -p FragmentPath -p DropInPaths
sudo systemctl restart example.service
systemctl status example.service --no-pager -l
journalctl -u example.service -n 50 --no-pager
実務ポイント：変更したファイルとsystemdが実際に読んでいるファイルが同じかを
systemctl cat と FragmentPath で確認すると、「別パスを編集していた」事故を減らせます。変更が反映されたか確認する
systemctl cat example.service
systemctl show example.service -p FragmentPath -p DropInPaths -p ExecStart
systemctl status example.service --no-pager -l
依存関係を変えた場合は、Unitの表示だけでなく依存関係側も確認します。
systemctl list-dependencies example.service
systemctl show example.service -p After -p Wants -p Requires
よくある勘違い
daemon-reloadを実行すればサービスも再起動されると思う- アプリ設定の再読込とUnit定義の再読込を同じものと考える
- 構文確認をせずにreload/restartまで進める
systemctl catで実際のUnit本体・drop-inを確認しない- 変更後のstatusとjournalを確認しない
関連ガイド
関連ガイド