我有一个 systemd 服务显示以下错误service start request repeated too quickly, refusing to start
我了解该服务配置为在失败时重新启动，并且它会一次又一次地重新启动。但它究竟何时拒绝重新启动？是否有定义它的限制或数字？
此外，这too quickly到底是什么意思，是在给定的时间段内重启次数的限制吗？
答案1
默认限制是允许在 10 秒内重新启动 5 次。如果服务由于Restart=服务定义中的配置选项而超过该阈值，它将不会再尝试重新启动。
速率由StartLimitIntervalSec=和StartLimitBurst=选项配置，并且Restart=选项控制 SystemD 何时尝试重新启动服务。
更多信息在man systemd.unit和man systemd.service。
然后使用systemctl daemon-reload重新加载单元配置。
答案2
不完全相同的问题，但这是在搜索时出现的问题......
如果您只想启动它而忽略这个荒谬的限制废话（例如在 Debian 上，在配置服务之前 apt 自动启动服务的必然结果，注定它们会失败、循环并达到限制，用启动限制错误大量地向日志中发送垃圾邮件，您甚至无法轻易读出原因）：
看https://bugzilla.redhat.com/show_bug.cgi?id=1016548Michal Schmidt 说你可以在其中找到它man systemd.service并建议重置失败状态：
systemctl reset-failed <service name>
现在您的服务可能会启动。或者至少它无法启动的实际最新原因应该在日志中，例如journalctl -x
答案3
值得注意的是，有些故障似乎会引发此错误，但原因却不同。
我注释掉了默认的 bantime，并插入了一个替代的内联
**bantime = 7200 #3600**
我还添加了一个新部分[sasl]，其中包括一个过滤器名称，该名称与我所关注的文章中给出的名称不同。
fail2ban 没有出现上述错误，而是拒绝重新启动，导致
服务启动请求重复太快，拒绝启动错误
仅当我注释掉 [sasl] 部分时，我才收到一个指向无效 bantime 的错误，从中我得知它无法处理内联注释。
当我修复该问题并取消注释新的 [sasl] 部分时，我收到一条错误消息，提示未找到过滤器。替换正确命名的过滤器后，fail2ban 便按预期重新加载。
因此，如果您进行更改并收到此错误，请确保在尝试修复症状之前删除更改并仍然收到相同的错误。
答案4
就我的情况而言，错误消息有些误导。失败的原因是由于机器之间的复制。行
User=my_user
在我的服务配置文件中/etc/systemd/system/infinite_script.service是罪魁祸首。
新机器不认识这个用户。更改为User=root解决了这个问题。