One of these days I’m going to figure out why my nightly/hourly[1] rsync backup does something strange when the clocks change. But the problem is that I have to wait 6 months or a year to see if the change I made made any difference, and then I think “nah, I’ll just fix it manually next time it happens just like I did this time”. I think it’s getting confused by the double hour when the clocks go back and thinking it has to do the nightly backup again. Come to think of it, the nightly does happen at 1:15, and when the clocks go back we get two 1:15s, don’t we? I don’t want to make it 2:15, because when the clocks go forward we don’t have one of those. Maybe I’ll make that 4:15 and avoid the whole problem.
[1] Every hour it backs up my home Linux box to an external hard drive. Once a night, it backs up my colo box to my home box, and then backs up that to the external hard drive as well.
I make it a habit to never ever schedule nightly stuff for the time-change hour; either get it done right after midnight, or wait until 3:01 or so. Interpret political interference with the clock as damage and route around it.
Hourly stuff is a bit more difficult. If it’s producing a timestamped output, then checking if its output already exists and punting right away takes care of the double run in the fall, and trying not to miss the missing hour in the spring too badly handles that one.
Yeah, we definitely get two 1:15AMs when DST ends. My approach to this problem has always been to avoid 1-3AM Sundays for any scheduled tasks, or alternately to just make the server time set to UTC and never deal with it again, which is the approach we’ve been moving to at work.
I’ve run jobs in the “magic” hour via cron without any problems. It should be counting UNIX seconds, which do not have a discontinuity when the clocks are rolled forward/backward. Does the job hang or is it skipped?
No, the problem is that it does an rsync with a “link-dest” of “$YESTERDAY”. Unfortunately it completes once at 1:15 and sets “$YESTERDAY” to Sunday, and then it runs at the second 1:15 and tries to do an rsync with link-dest set to itself, which means it backs up everything instead of just what changed. And backing up the whole system over the internet takes hours and wastes disk space.
Yeah, this is something I keep meaning to experiment with. I think different versions of cron behave differently. I work around it by not scheduling jobs between 1am and 3am (except for standard hourly jobs, of course).
*ponder* I wonder if I could build some VMs (maybe under UML) and mess around with the clock inside them… in my CFT 🙂
@gordon: cron time specs (eg “15 2 * * *”) are interpreted as localtime, not gmtime. A job scheduled for “15 1 * * *” would potentially match that time twice when the clocks go back; a job scheduled for “15 2 * * *” would potentially not match at all when the clocks go forward. Now a good crond should recognise that these problems and either skip the second run or immediately schedule a missed run, but this appears to be implementation specific. (A job scheduled for “15 * * * *” probably should run both times when clocks go back).
Paul, how about setting the colo box’s time zone to sweet timezone-less UTC?
So why not test for this situation and abort if it’s already run today?
Because it happens once a year and every time I think to do anything about it I’ve got to wait a year to see if what I did worked.
Surely you could test it by running the job twice on the same day?