科技 · 实用指南
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中的生效路径为准。
依赖失败要检查命名的前置项与顺序关系，而不是反复启动依赖方。网络target正常不保证远端、挂载、socket或凭据就绪。保存依赖项自己的状态与日志，避免把一个故障误判成两个限速问题。
5. 检查单元类型、就绪信号与时间窗
让Type=匹配进程模型。持续前台运行通常适合Type=simple或Type=exec；会fork的程序需要正确模型，必要时还要可靠PIDFile；Type=notify需要就绪通知。错配会让systemd认为启动失败，即使子进程短暂存在。
若墙上时钟看到的启动数少于burst，先核生效属性与全部drop-in，再比较带单调时间的journal。systemd上游案例说明挂起会使单调时间窗口看起来比墙上时钟更长；这是窄分支，不是通用解释。
6. 修复一次、重置一次，并验证原路径
只做第一次失败支持的最小修正。仅当单元文件或drop-in变化时运行daemon-reload。随后一次systemctl reset-failed UNIT、一次受控启动，并观察状态与新日志。确认NRestarts不再增长，服务达到真实就绪条件，而非只短暂显示active。
服务稳定后，才为已测的瞬态失败调整RestartSec、StartLimitIntervalSec或StartLimitBurst。保持有界限制，记录理由，并可用OnFailure收集证据或告警。重试仍失败就保留新错误，沿新分支继续。
