私は数ヶ月間systemdタイマーを安定して使用してきましたが、最近トリガーされたサービスジョブがまだ実行されていないという警告を受けました。を使用すると、systemctl list-timers実際にスケジュールされたトリガーイベントは表示されなくなります。
偶然だと思い、タイマーを再起動して使用して、次のlist-timers実行が期待どおりに予定されていることを発見しました。ただし、タイマーは一度だけ実行され、次の時間が再開されるまで新しいイベントのスケジュールを停止します。
Ubuntu 18.04私はこれがシステムのバグかもしれないと思ってホストをからにアップグレードしましたが、Ubuntu 20.04問題は解決しません。システムタイマーが新しいイベント配信を停止する原因は何ですか？。
トリガーされたサービスが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
考えられる原因が見つかりました。タイマーが実行されているサービスに無限ループになるバグがありました。システムタイマーは通常サービスの2番目のインスタンスを呼び出さないため（すでに実行中のサービスがある場合）、タイマーは新しいイベントの予約を停止したようです。
私が得た一つの手がかりは、停止したタイマーと新しく開始されたタイマーを比較することでした。systemctl show foo.timerステータスの詳細を確認するために、タイマーを使用して以下を確認しました。
SubState=running
新しく開始されたタイマーがその場を置き換えますSubState=waiting。
この時点で私はやるべきことをしました。systemctl status対象サービスで使用することでした。もちろん、最後の時間から実行を続けていることを示し、タイマーが再び実行されるのを防ぎました。