Thanks for your quick reply.
Am 06.04.24 um 06:37 schrieb Alexandre Detiste:
Can you please try to reproduce the problem without systemd-cron involved;
by copying the .timer / .service / .sh triplet from /run/systemd/generator
into /etc/systemd/system and see what happens when
you do manually what cron-update.service would do.
It does:
- systemctl daemon-reload
- systemctl restart <your_job>.timer (via cron.target)
- systemctl reset-failed <your_job>.timer
(hint: systemctl cat cron-update.service)
If the same problem persists; then the bug is definitively in systemd itself.
Yes, indeed, on restart of the .timer unit, the service is executed
immediately!
So, my mwe looks like this:
$ cat /etc/systemd/system/timerconfusion.timer
[Timer]
Unit=timerconfusion.service
OnCalendar=*-*-* *:0/5
$ cat /etc/systemd/system/timerconfusion.service
[Service]
Type=oneshot
ExecStart=/bin/bash -c 'date --iso-8601=seconds >>
/var/log/timerconfusion.log'
$ systemctl daemon-reload
$ systemctl starttimerconfusion.timer
$ # wait until timer is executed for the first time
$ cat /var/log/timerconfusion.log
2024-04-06T12:55:07+02:00
$ systemctl restart timerconfusion.timer
$ cat /var/log/timerconfusion.log
2024-04-06T12:55:07+02:00
2024-04-06T12:55:24+02:00
In my test, only the very first restart of the timer after a regular
scheduled timer execution caused an extraneous service start.
Thanks.
Best,
Maximilian
