Fix calculation of nextExec of cronjobs

To properly calculate nextExec we must not specify the TIME_NOW parameter,
because if the cronjob is run on the scheduled time the nextExec() will
return the current time.

Not passing the TIME_NOW parameter adds at least 120 seconds of delay to
prevent this issue.

This bug was introduced in commit 485f8e1888824b862823de983e019afcb9bca7ce.
When moving the update of the execution time the calls were not correctly
moved and the explicit passing of TIME_NOW was added.

diff --git a/wcfsetup/install/files/lib/system/cronjob/CronjobScheduler.class.php b/wcfsetup/install/files/lib/system/cronjob/CronjobScheduler.class.php
index d36d2aec3d16887df1ede5f6ec3bd4e984a17d58..863339baa010acedc6b37cd0f2b841fa191cce54 100644 (file)
--- a/wcfsetup/install/files/lib/system/cronjob/CronjobScheduler.class.php
+++ b/wcfsetup/install/files/lib/system/cronjob/CronjobScheduler.class.php
@@ -207,7 +207,7 @@ class CronjobScheduler extends SingletonFactory {
                                // stuck jobs. If the timestamps are updated after executing then concurrent requests
                                // might believe that a cronjob is stuck, despite the cronjob just having started just
                                // a few milliseconds before.
-                               $data['nextExec'] = $cronjob->getNextExec(TIME_NOW);
+                               $data['nextExec'] = $cronjob->getNextExec();
                                $data['afterNextExec'] = $cronjob->getNextExec($data['nextExec'] + 120);
                                $data['lastExec'] = TIME_NOW;