Linuxのsystemdサービスが「Start request repeated too quickly」で起動しなくなった時の対処手順｜systemctl reset-failedとStartLimitBurstの設定方法

「systemctl restart nginx」を実行したら、起動を拒否するメッセージが返ってきた——そんな場面に遭遇したことはないだろうか。

Start request repeated too quickly.

コマンドを何度打ち直しても同じだ。ログを見ようとすると同じメッセージの繰り返し。これはsystemdの「起動制限機能」が動いているサインだ。nginxに限らず、mysqld、postfix、自社のアプリケーションサービスでも起きる現象だ。

この記事では、RHEL 9系／Rocky Linux 9系／Ubuntu 24.04 LTSを想定環境として、このエラーの仕組みを理解したうえで、journalctlを使った根本原因の調査方法、systemctl reset-failedによる即時対処、そしてStartLimitBurstを使った恒久設定まで、一連の手順を解説する。

「Start request repeated too quickly」とはどういう意味か｜StartLimitの仕組み

systemdには、サービスが短時間に何度も起動・終了を繰り返した場合に、「これ以上の起動試行は危険だ」と判断し、一時的に起動を停止する仕組みがある。

この制限に関わる主なパラメータは次の2つだ。

・StartLimitBurst: 許容する起動試行の最大回数（デフォルト: 5回）
・StartLimitIntervalSec: 試行回数をカウントする時間窓（デフォルト: 10秒）

デフォルト設定では「10秒以内に5回起動に失敗した場合」に制限が発動する。制限が発動するとサービスの状態が failed になり、以降の systemctl restart は「Start request repeated too quickly」を返すだけで、起動処理が走らなくなる。

制限がかかった状態での systemctl status の出力例（環境により異なります）:
Active: failed (Result: start-limit-hit) という行が出ていれば、起動制限が発動している状態だ。start-limit-hit という文字が見えたら、このあと説明する手順を実行しよう。

【即時対処】systemctl reset-failedで起動制限を解除する

起動制限を解除するには systemctl reset-failed コマンドを使う。サービスの failed 状態をリセットして、再度起動できるようにする。
重要な注意点： reset-failed は起動制限のカウンタをゼロに戻すだけだ。サービスが落ちていた根本原因は何も直っていない。リセットだけして再起動すれば、同じサイクルがすぐに繰り返され、またすぐに「Start request repeated too quickly」になる。

「とりあえず起動制限を解除してサービスを復旧させる」ことと「サービスが落ちた原因を修正する」ことは別の作業だ。次のセクションで根本原因を必ず調査すること。

根本原因を調査する3ステップ

1. journalctlでクラッシュ直前のエラーを読む

サービスが起動直後に落ちる場合、必ずsystemdのジャーナルにエラーメッセージが記録されている。起動制限が発動した後でもログは残っているので、まずここを確認する。
出力例（環境により異なります）:
この例では「ポート80が既に他のプロセスに使われている」ことが原因だ。Linux ポート確認の全コマンドを参考に、ss -tlnp | grep :80 でどのプロセスがポートを占有しているか特定できる。

エラーメッセージを読むだけで、設定ファイルの問題なのか、ポートの競合なのか、依存サービスが起動していないのかが分かることが多い。

2. systemctl statusで停止の種類を把握する

systemctl status の Active: 行には、サービスがどのような形で終了したかが書かれている。停止の種類によって調査の方向が変わる。
Active: に表示される停止種別の読み方:

・failed (Result: exit-code): ExecStartのプロセスが非0で終了した。ログに詳細なエラーが出ている
・failed (Result: signal): シグナルで強制終了された。OOMキラーに殺された可能性がある（dmesg | grep -i "oom" で確認）
・failed (Result: start-limit-hit): 起動制限が発動している。まず journalctl で根本原因を調べる
・failed (Result: timeout): ExecStartの開始タイムアウトを超えた。TimeoutStartSec の延長や依存サービスの遅延が原因のことがある

start-limit-hit だけ見て「カウンタをリセットすれば直る」と判断するのは危険だ。起動制限は「何度も落ちた結果」であり、原因そのものではない。journalctl と合わせて必ず根本原因を確認すること。

3. アプリケーション固有のログを確認する

サービスによっては、systemdジャーナルではなく独自のログファイルに詳細な原因が出ていることがある。

・nginx: /var/log/nginx/error.log
・MySQL / MariaDB: /var/log/mysql/error.log または /var/log/mariadb/mariadb.log
・Postfix: /var/log/maillog
・自社サービス: ExecStart で指定したプロセスの標準エラー出力（journalctl -u サービス名 に統合されている場合が多い）

journalctl では先頭数行しか見えないケースでも、アプリケーションのログには詳細なスタックトレースやライブラリのエラーが残っていることがある。systemdのジャーナルとアプリケーションのログ、両方を確認する習慣をつけておきたい。

サービスが何度も落ちる主な原因パターン

「Start request repeated too quickly」が頻発する背景には、サービスが短時間で繰り返しクラッシュしているという事実がある。起動直後のクラッシュであれば、次のパターンが多い。

・設定ファイルの構文エラー: nginx の nginx -t、MySQL の mysqld --validate-config 等で事前チェックできる。再起動の前に設定検証を実行するのが基本だ
・ポートの競合: すでに別のプロセスがポートを占有している。ss -tlnp で確認する
・必要なファイルやディレクトリの欠損: 設定ファイルが存在しない、PIDファイルのディレクトリがない、など。journalctl に「No such file or directory」が出ていたらこのパターン
・権限の問題: サービスを実行するユーザーが必要なファイルを読めない。journalctl に「Permission denied」が出ていれば ls -la と stat で確認する
・依存サービスが起動していない: データベース接続先が存在しない、NFS共有がマウントされていない、など。systemctl list-dependencies サービス名 で依存関係を確認できる
・OOMキラーによる終了: メモリ不足でカーネルが強制終了させている。dmesg | grep -E "oom|killed" で確認する。この場合は停止種別が signal になることが多い
・起動タイムアウト: データを大量に保持するサービスが起動処理中にsystemdのタイムアウトを超えてしまう。TimeoutStartSec の延長で対処する

起動直後のクラッシュであれば、設定エラー・ポート競合・ファイル欠損の3つが原因のほとんどを占める。Linux Master Proセミナーでは、このような実際のサービス障害に近い演習環境でトラブルシューティングを練習している。

StartLimitBurstとRestartSecを設定して再発を防ぐ

根本原因を修正して再起動できたとしても、サービスが今後も不定期にクラッシュするような性質を持つ場合（依存サービスの起動順序による一時的な接続失敗など）は、systemdの再起動設定を見直しておくとよい。

1. systemctl editでdrop-inファイルを作成する

/usr/lib/systemd/system/ 配下のユニットファイルはパッケージ管理システムが管理している。直接編集するとパッケージ更新時に変更が上書きされてしまうため、設定変更には drop-in ファイルを使う。
systemctl edit を実行するとエディタが起動し、/etc/systemd/system/nginx.service.d/override.conf に設定を書き込める。保存すると自動的に daemon-reload が実行される。元のユニットファイルには手を触れないため、パッケージ更新後も設定が維持される。

2. StartLimitBurstとStartLimitIntervalSecを調整する（[Unit]セクション）

StartLimitBurst と StartLimitIntervalSec は [Unit] セクションに記述する。
StartLimitIntervalSec=0 と設定すると起動制限が無効になるが、無限クラッシュループに陥った場合にサーバーへ深刻な負荷がかかることがある。制限を無効化するより、次の RestartSec でリトライ間隔を延ばす方法の方が安全だ。

3. RestartSecでリトライ間隔を延ばす（[Service]セクション）

RestartSec のデフォルト値は100ミリ秒だ。これだけ短いと、サービスが10回クラッシュするのに1秒もかからない。StartLimitIntervalSecの10秒以内に5回制限には、あっという間に達してしまう。

RestartSec=5 のように5秒以上に設定しておけば、サービスが繰り返し落ちても、1回の試行ごとに5秒の間隔が開くため、起動制限に達しにくくなる。

4. 設定反映と動作確認

systemctl show の出力に設定した値が反映されていれば、drop-inが正しく読み込まれている。値が変わっていない場合は、systemctl daemon-reload を再実行してから確認し直すこと。

本記事のまとめ

やりたいこと	コマンド・設定
起動制限が発動しているか確認する	systemctl status サービス名（start-limit-hitを確認）
起動制限を即時解除する	systemctl reset-failed サービス名
クラッシュ前後のログを読む	journalctl -u サービス名 -n 100 --no-pager
OOMキラーによる終了を確認する	dmesg | grep -E "oom|killed"
起動試行の許容回数を増やす	drop-inで StartLimitBurst=10（[Unit]セクション）
カウント窓を広げる	drop-inで StartLimitIntervalSec=60（[Unit]セクション）
再起動間隔を延ばす	drop-inで RestartSec=5（[Service]セクション）
drop-inファイルを作成・編集する	systemctl edit サービス名
設定変更を反映する	systemctl daemon-reload

「Start request repeated too quickly」が出た時の手順をまとめると次のとおりだ。

・まず systemctl status で停止種別（start-limit-hit / exit-code / signal）を確認する
・journalctl -u サービス名 -n 100 でクラッシュ直前のエラーを読む
・根本原因（設定ミス・ポート競合・ファイル欠損・OOMなど）を修正する
・systemctl reset-failed サービス名 でカウンタをリセットしてから再起動する
・再発するなら systemctl edit でdrop-inを作成し、StartLimitBurst・RestartSec を調整する

systemdのサービス管理を正しく理解することで、本番サーバーのトラブル対応が落ち着いてできるようになる。サービス障害の調査ルーティンとして、ここで紹介した手順を身につけておこう。

---

• 前のページへ：LinuxのOpen Files上限をサービス別に正しく設定する方法｜limits.confとsystemd LimitNOFILEの優先順位とdrop-inで永続化する手順
• この記事の属するカテゴリ：Linuxトラブルシューティングへ戻る