dcron icon indicating copy to clipboard operation
dcron copied to clipboard

handle system date changes

Open hcodina opened this issue 7 years ago • 2 comments

Hi, I have a problematic use case and before i fill a github issue, i would like to know your opinion about it.

Let's say we are the October 11 2018. I have cron jobs scheduled "@hourly" and "@daily" and everything is correct.

I manually change my system date and i set it to January 01 2000. I have the impression that my jobs will never be run until October 2018 (18 years to wait). I expect my job to be scheduled one hour or one day after their last run or at least one hour one day after my date change but not 18 year.

I would like to known what kind of workaround we can do to handle this use case.

In main.c you handle "big" delta as :

if (dt < -60*60 || dt > 60*60) {
	t1 = t2;
	printlogf(LOG_NOTICE,"time disparity of %d minutes detected\n", dt / 60);
}

Maybe we can add something to fix cl_LastRan + timestamp file, cl_NotUntil values in this block.

What do you think about this idea ? Do you have any other idea to handle system date changes in order to keep @xxxx jobs scheduled hourly, daily, ... ?

Best regards, Herve Codina

hcodina avatar Oct 11 '18 09:10 hcodina

Hi Herve,

I haven't been active with dcron for a while, but I'm aiming to get my attention back to it before the end of the year. I am keeping track of requests people have made.

Re the issue you describe, I agree it makes sense to do something to reconcile the @hourly @daily jobs with a timestamp seen to be set into the future. How about something like this (roughly): if when we check the timestamp, we see that it's set more than an hour into the future, we don't consider it to have expired (so we don't run the @hourly job then) but we update the timestamp with the current time. So one hour later, the @hourly job will run. This is just an offhand, first thought.

dubiousjim avatar Oct 11 '18 10:10 dubiousjim

Sounds good.

We can check timestamp when we read it (ie ReadTimestamps()) It seems a good place to update "invalid" timestamp.

We can plan to force a ReadTimestsamps() also on "big" delta detected in order to update "invalid" timestamp as we detect a potential date change.

hcodina avatar Oct 11 '18 12:10 hcodina