David Goodenough wrote: > Bob Proulx wrote: > > Then I would create a new script that would set the clock to as > > reasonable of a value as possible. You don't have a real time value > > yet but most importantly you don't want to set it to a time that is > > before the system was stopped. So I would look for a file on the > > filesystem that is always active on the system. I would extract the > > time from that file and use it as the basis for the new system time. > > Then at the very least you would have monotonically increasing time. > > You would not be duplicating any previous times. Then when NTP sets > > the system to the actual time it may jump forward. But that is going > > to happen anyway. And then at least it won't fire cron tasks multiple > > times. > > well the 1st Jan 1970 00:00am is as good a a value as any, how would > setting it to some other value help? Because it ensures that the system time is always monotonically increasing. Time points are never repeated. Monotonically increasing time is an essential point of time keeping. Otherwise you could have system logs duplicated. Otherwise you could have cron trigger cronjobs multiple times for the same task. But I am surprised by your question. If you believe that the Unix zero epoch is always as good of a time as any then what is your concern? It can't be cron since those two concerns are one concern inextricably intertwined. Being concerned about cron *is* being concerned that the system has a proper monotonically increasing clock time. > What does cron do with events that should have happened during the > jump that ntpdate will cause in the clock. Nothing. Since those time points did not happen then cron did not trigger them. The anacron package mentioned by others is designed specifically to handle the cron.daiy et al scripts. That way if your machine is off at the time they would run but boots shortly afterward those tasks will still be run. Think of a laptop being suspended and resumed skipping over those times of day. With anacron installed those daily scripts will run later when the machine has been resumed. I am not really a fan of anacron myself but it does provide a useful function for those cases. > If they are ignored then I suppose I am safe provided I do not set > things too close to 00:00am. Mostly, yes. Don't have any cronjobs within a reasonable window of time and you will be fine. For example I avoid scheduling jobs between 2am-3am because in my timezone that is when DST changes happen and that will cause tasks to either be skipped or run twice. > But then when does it do daily and monthly tasks, 00:00am would seem > like a reasonable time, or does it do it later to avoid problems > with daylight saving changes. You can look this up for yourself: $ cat /etc/crontab # m h dom mon dow user command 17 * * * * root cd / && run-parts --report /etc/cron.hourly 25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily ) 47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly ) 52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly ) Since 6am is outside most countries DST changes the problem of DST is avoided. Bob
Attachment:
signature.asc
Description: Digital signature