Bug#1068439: systemd-cron: cron-update causes re-run of some past timers

[Alexandre Detiste]

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  a écrit :

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

Bug#1068439: systemd-cron: cron-update causes re-run of some past timers

[Maximilian Stein]

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

Bug#1068439: systemd-cron: cron-update causes re-run of some past timers

[Maximilian Stein]

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 .timer  (via cron.target)
  - systemctl reset-failed .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

Processed: Re: Bug#1068439: systemd-cron: cron-update causes re-run of some past timers

[Debian Bug Tracking System]

Processing control commands:

> tag -1 +moreinfo
Bug #1068439 [systemd-cron] systemd-cron: cron-update causes re-run of some 
past timers
Added tag(s) moreinfo.

-- 
1068439: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068439
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1068439: systemd-cron: cron-update causes re-run of some past timers

[Alexandre Detiste]

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 .timer  (via cron.target)
 - systemctl reset-failed .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  a écrit :
> Today I noticed that a run of cron-update.service apparently causes
> some past cron jobs to re-run.
>
> 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.

Bug#1068439: systemd-cron: cron-update causes re-run of some past timers

[Maximilian Stein]

Package: systemd-cron
Version: 2.3.4-1
Severity: normal

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