Dear Maintainer,

Today I noticed that a run of cron-update.service apparently causes
some past cron jobs to re-run.

In particular, I have a cron job of "5 5 5 * *" which correctly
executed this morning at 2024-04-05T05:05:08.401635+02:00.

Then, at 6:24 an automatic configuration script caused a re-run of
cron-update.service. This, however, did not only cause a restart of
the generated timer unit but also started the service itself, i.e.,
the service ran again at 2024-04-05T06:24:40.798393+02:00.

I was able to reproduce the behavior with other timers, too. It seems
that the generated cron services are executed by cron-update.service
if they are within a certain time limit in the past.

Best,
Maximilian

control: tag -1 +moreinfo

Thank you for your report.

systemd-cron attempts to be the shallowest possible
wrapper around systemd.

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.

Greetings

Le ven. 5 avr. 2024 à 11:15, Maximilian Stein <m@steiny.biz> a écrit :

Thanks for your quick reply.

Am 06.04.24 um 06:37 schrieb Alexandre Detiste:
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

So, should this issue be forwarded/moved to systemd then?

Hi.

Yes. [*]

I will keep this one bug open here if in any case someone stumble on the
same problems.

[*]: this mean checking the Debian & upstream bug tracker for a possible
duplicate,  this might take a while; do you want to have a look ?

At times I audit system/cronie/vixie cron for bugs/feature parity/ideas,
but right now systemd-cron development is pretty done/dormant.

Greetings

Le lun. 15 avr. 2024, 08:55, Maximilian Stein <m@steiny.biz> a écrit :