我已经可靠地使用 systemd 计时器几个月了，但最近收到警报，触发的服务作业尚未运行。当我使用时systemctl list-timers，确实我看到没有更多的触发事件被安排。
我认为这是一次侥幸，因此重新启动了计时器，使用list-timers并发现现在下一次运行已按预期安排。但现在计时器似乎只触发一次，然后就停止安排新事件，直到时间重新开始。
我认为这可能是 systemd 错误，因此我将主机从 升级Ubuntu 18.04到，Ubuntu 20.04但问题仍然存在。什么会导致 systemd 计时器停止调度新事件？。
我检查了触发的服务是否挂起并运行超过 24 小时，但它在大约 8 小时内可靠地完成。
这是定时器单元：
[Unit]
Description=Runs service
[Timer]
Unit=myservice.service
# Run every day at this time.
OnCalendar=*-*-* 10:00:00
[Install]
WantedBy=timers.target
以下是.service执行一些大约需要 8 小时才能完成的维护任务的文件：
[Unit]
Description=Do things
# Send email if this fails
OnFailure=status-email-devops@%n.service
[Service]
Environment="[email protected]"
User=example
Group=example
UMask=002
ExecStart=do-thing
ExecStartPost=/usr/local/bin/aws cloudwatch put-metric-data --region us-east-1 --namespace Example --dimensions Host=%H --metric-name example --value 1
StandardOutput=journal
这是 systemd v245 的情况。
答案1
我发现了一个可能的原因：计时器运行的服务出现了一个错误，该错误变成了无限循环。由于 systemd 计时器通常不会标准服务的第二个实例（如果已经有一个服务正在运行），因此计时器似乎已停止安排新事件。
我得到的一条线索是比较卡住的计时器和新启动的计时器。我使用systemctl show foo.timer计时器来获取有关状态的更多详细信息，并看到了这一点：
SubState=running
新启动的计时器取而代之的是SubState=waiting。
此时，我做了我应该做的事情，即systemctl status在目标服务上使用，这当然表明它仍在上次运行，从而阻止计时器再次触发。