Cron: Use same date/time for each job

[mjansenDatabay]

See: https://mantis.ilias.de/view.php?id=41007

[klees]

Hi @mjansenDatabay,

please don't, this looks like a food gun that would be lying around or even already a bug to be introduced

Let me explain: The wording for that functionality ("date time provider") we would be modifying here suggests, that I can indeed get the current datetime by using the closure. Even though it is only used for checkSchedule in the class from the core, it is indeed available to be used for all derived classes as it is protected. So this could already be used for other purposes in some existing cron job. Even if it might not be used for other purposes now, the wording at some point will catch someone by surprise, as it strongly suggests that the function will yield a changing value, which would be a constant one after this change here.

Even more, I would strongly suggest that the original ticket is the result of a misconfiguration which even might not necessarily be fixed by this change. Let me elaborate: The job is scheduled to run every 5 minute. The cron.php is also be scheduled to be run every 5 minute. So, every 5 minutes we check, if the job shall run again. Let t_c be the moments when cron.php triggers. Then, depending on start up time of the script, and other cronjobs maybe, the job is actually triggered at t_j = t_c + e_1 where e_1 > 0 is the time until the cronjob actually runs. Let d_c be the scheduled delay for the cron.php and d_j be the scheduled delay for the job. Then t_j + d_j <= t_c + d_c is the check that shall determine if the job will run the next time. Then insert t_j from above t_c + e_1 + d_j <= t_c + d_c. Subtract t_c on both sides: e_1 + d_j <= d_c and finally set d_j = d_c as in the ticket and subtract again: e_1 <= 0. Before, the execution time e_1 was determined by the script startup time and the jobs executed before, after this e_1 will be the startup time (more specifically: the time until line 44 is reached). This might be 0 if measured in s or ms but even then it isn't necessarily be 0 (and never smaller then 0...) and the fix will fail again....

The general problem here is: With the given configuration, we are trying to approximate a dirac comb with another dirac comb of the same period, which will not work very well. Like a moiree effect in time... The correct solution would be to use a function of much higher frequency for the approximation, which means that the cron.php should e.g. be triggered every minute to allow to approximate cron jobs with 5 minute schedule with a sufficient accuracy.

Hope this makes some sense...

Kind regards!

[klees]

Sorry, it somehow got me there 😁

[klees]

And, on a second thought, something like 57s would be even better =)

[mjansenDatabay]

I agree with your remarks, Richard. When thinking about the PR yesterday evening, I also came to the conclusion that this will not fix the actual issue.

Furthermore, we also discussed this internally this morning, and I came to the same conclusion as you:

The correct solution would be to use a function of much higher frequency for the approximation, which means that the cron.php should e.g. be triggered every minute to allow to approximate cron jobs with 5 minute schedule with a sufficient accuracy.