科技 · 實用指南
systemd 顯示「啟動要求重複過快」？重設前先找第一次失敗
最後的啟動限速訊息通常是保護欄，不是根因。先保存生效單元與最早失敗，再依證據修復後清除計數。
「啟動要求重複過快」表示systemd因單元在設定窗口內啟動過多而拒絕再啟動。限速器出現在多次嘗試之後，通常不會指出程序最初為何失敗。
重設計數、放寬限制或繼續啟動前，先保存生效單元與最早失敗日誌。安全流程要把限速狀態與程序、身分、路徑、相依與單元模型證據分開。
1. 把拒絕視為保護欄，而非根因
systemd對單元啟用實施啟動限速。啟動在StartLimitIntervalSec內超過StartLimitBurst後，新的啟用會被拒絕，Result可能為start-limit-hit。自動重啟也受此邊界限制，因此Restart=always不能讓確定性失敗變安全。
不要先提高StartLimitBurst或設StartLimitIntervalSec=0，否則受控失敗可能變成緊密崩潰循環。reset-failed也不是修復；它只清除失敗狀態和計數，供根因修正後一次受控重試。
2. 再次啟動前凍結證據台帳
先記錄單元屬於系統或使用者管理器，再保存systemctl status、systemctl cat及systemctl show中的FragmentPath、DropInPaths、User、Group、Type、ExecStart、WorkingDirectory、EnvironmentFiles、Restart、RestartUSec、StartLimitIntervalUSec、StartLimitBurst、NRestarts與Result。使用者單元應在對應登入環境使用--user。
保存第一次失敗附近的journal，不只保存最新拒絕。用journalctl -u UNIT限制時間窗；若時間有爭議，保留單調時間戳。daemon-reload、套件修復或drop-in編輯會改變證據，先留副本。
3. 找到重啟循環背後的第一次失敗
向前讀過「Scheduled restart job」與「Start request repeated too quickly」，停在最早的具體錯誤：退出狀態、訊號、執行檔錯誤、缺少路徑、權限拒絕、未知使用者、相依失敗、就緒逾時或watchdog。該行決定下一分支。
程序立即退出時，對照實際ExecStart與程序預期的前景模式。只在安全時以設定使用者、工作目錄和必要環境作診斷；命令在管理員互動shell成功，不代表服務環境也能執行。
4. 依執行檔、身分、路徑與相依分支
執行檔失敗要核絕對路徑、執行位元、解譯器或載入器、擁有權與掛載策略。身分失敗應恢復預期使用者或群組及目錄存取，不要改成root。設定或環境檔缺失時，以systemctl show與WorkingDirectory的生效路徑為準。
相依失敗要檢查命名的前置項和順序關係，不要反覆啟動相依方。network target正常不保證遠端、掛載、socket或憑證就緒。保存相依項自己的日誌與狀態。
5. 檢查單元類型、就緒與時間窗口
讓Type=符合程序模型。持續前景執行通常適合Type=simple或Type=exec；會fork的程序要正確模型與必要時可靠PIDFile；Type=notify需要就緒通知。錯配會使systemd判定啟動失敗，即使子程序短暫存活。
若牆上時鐘看到的啟動數少於burst，先核生效屬性與全部drop-in，再比較帶單調時間的journal。上游案例顯示掛起會使單調時間窗口看似更長；這是窄分支，不是通用解釋。
6. 修復一次、重設一次並驗證原路徑
只做第一次失敗支持的最小修正。僅在單元檔或drop-in改變時執行daemon-reload。接著一次systemctl reset-failed UNIT、一次受控啟動，並觀察狀態與新日誌。確認NRestarts不再增加且服務達到真實就緒。
服務穩定後才為已量測的暫時失敗調整RestartSec、StartLimitIntervalSec或StartLimitBurst。保持有界限制、記錄原因，並可用OnFailure收集證據。重試仍失敗就保存新錯誤再分支。
