systemdの Restart 設定は、サービスの可用性を高める一方で、 設定を誤ると再起動ループや障害の長期化を引き起こす非常に危険な項目です。 本記事では、実務で頻発する事故例を踏まえながら、正しいRestart設計の考え方を解説します。
目次
この記事を読むとできるようになること
systemdのRestart設定がどのような条件で動作するのかを正しく理解し、 サービス特性に応じた最適なRestartポリシーを設計できるようになります。 また、再起動ループが発生した際の原因切り分けや、事故を防ぐ設定例も理解できます。
Restart設定の基本動作
Restart は、サービス終了時に systemd が再起動を行うかどうかを制御します。 代表的な値は以下の通りです。
Restart=no
Restart=on-failure
Restart=always
Restart=on-abnormal
| 設定値 | 再起動条件 |
|---|---|
| no | 再起動しない(デフォルト) |
| on-failure | 異常終了時のみ再起動 |
| always | 正常終了でも再起動 |
| on-abnormal | シグナル終了・タイムアウト時のみ |
最も事故が多いのは Restart=always です。
よくある障害パターン①:Restart=always による無限再起動
発生状況
- 設定変更直後からCPU使用率が急上昇
- journalctl に同じ起動ログが大量出力
- systemctl stop が効かない
原因
サービスが即時終了する状態で Restart=always が設定されていると、 systemdはミリ秒単位で再起動を繰り返します。
ログ例
systemd[1]: myservice.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: myservice.service: Scheduled restart job, restart counter is at 18923.
対策
- 基本は
Restart=on-failureを使用 - 即死するサービスには Restart を付けない
ベストプラクティス①:Restart=on-failure を基本にする
[Service]
Restart=on-failure
RestartSec=5
異常終了時のみ再起動されるため、 設定ミス・即時終了時の暴走を防止できます。
ベストプラクティス②:RestartSec を必ず設定する
RestartSec を設定しない場合、再起動が即座に行われます。
[Service]
Restart=on-failure
RestartSec=10
これにより、
- CPUスパイク防止
- ログ肥大化防止
- 一時的障害からの自然回復
が期待できます。
ベストプラクティス③:StartLimitを必ず併用する
systemd には再起動回数制限があります。
[Unit]
StartLimitIntervalSec=300
StartLimitBurst=5
5分間に5回失敗したら、それ以上起動しないという制御です。
この設定がないとどうなるか
- 永続的な再起動ループ
- 障害検知が遅れる
- CPU・IOリソース枯渇
ベストプラクティス④:oneshot・batch処理にはRestartを使わない
[Service]
Type=oneshot
ExecStart=/usr/local/bin/batch.sh
Restart=no
oneshot サービスに Restart を設定すると、 ジョブが無限実行される事故が発生します。
実務で安全なRestart設定テンプレート
[Unit]
Description=My Safe Service
After=network.target
StartLimitIntervalSec=300
StartLimitBurst=5
[Service]
Type=simple
ExecStart=/usr/local/bin/myservice
Restart=on-failure
RestartSec=10
[Install]
WantedBy=multi-user.target
このテンプレートは、
- 再起動ループ防止
- 障害検知性の確保
- 運用負荷の低減
をすべて満たします。
Restart設定トラブル時の確認チェックリスト
journalctl -u サービス名を確認したか- 終了コードは 0 か 1 か
- Type と PIDFile は一致しているか
- StartLimit に引っかかっていないか
- RestartSec が設定されているか
まとめ
systemdのRestart設定は、 「とりあえず always」ではなく、設計思想が重要です。
- 基本は Restart=on-failure
- RestartSec と StartLimit は必須
- oneshot・バッチ系では Restart を使わない
これらを守ることで、再起動が“味方”になります。
あわせて読みたい


systemd unitファイルの書き方完全テンプレ|実務で使える設定例付き
systemdのunitファイルは「なんとなく動く設定」と「事故らない設定」に大きな差があります。 本記事では、 最低限の構成 実務で必須の推奨設定 Type別テンプレ 障害を…
あわせて読みたい


systemd サービスが自動起動しない/Enable されないときの原因と対処
Linux サーバーでは systemd によるサービスの自動起動設定が広く利用されています。しかし、意図したサービスが再起動後に自動で立ち上がらない、あるいは systemctl e…
あわせて読みたい


Type=simple / forking / oneshot の違い|systemd Unit設定の落とし穴
systemdのUnitファイルで必ず登場する Type=。 この指定を誤ると、 起動したのにすぐ落ちる activeなのにプロセスがいない 依存サービスが正しく起動しない といった非…
