I think the other time logic would save it in the unprecedented case of 5 leap seconds.
My point was wrong because I was imagining some sort of sleep that could set you close enough to a minute that even UTC doesn’t help. I didn’t read the code before to see if this happened in the non-patched case. If that were the case, you could possibly want constantly increasing continuous time like GPS time:
http://leapsecond.com/java/gpsclock.htm
Does this mean all other UNIX-based OSes (or at least Vixie-cron using distros) don’t do this properly (e.g., running the same job twice when time jumps backwards)? That would be pretty messed up.
The timing on lobste.rs is sometimes irritating. Just yesterday someone opened an issue somewhere else about their system running without a cmos battery, so when they start again their system gets a new time from the internet, and in that second the timer library fires for some hundreds of times.
Interesting read. I still think servers should only ever use UTC as their timezone
UTC is not monotonically continuously increasing either. Leap seconds can skip your execution moment as well as repeat it.
Cron generally goes by the minute - so you would need a very large leap second to cause a problem in that case.
I’m picturing something where the wakeup time is close enough to 1 minute that you could miss a minute. It seems like it will do the right thing if it’s less than a 5 second leap, because they wait up to 65 seconds: https://salsa.debian.org/debian/cron/-/blob/master/debian/patches/features/Better-timeskip-handling.patch#L497
I think the other time logic would save it in the unprecedented case of 5 leap seconds.
My point was wrong because I was imagining some sort of sleep that could set you close enough to a minute that even UTC doesn’t help. I didn’t read the code before to see if this happened in the non-patched case. If that were the case, you could possibly want constantly increasing continuous time like GPS time: http://leapsecond.com/java/gpsclock.htm
I wrote a simple cron and my solution was to wake up in the middle of the minute to give 30 seconds of leeway on either side.
That’s probably 12 9s of correctness. As backblaze says, there’s more likelihood of an asteroid hitting the earth…
For sure. But, if a server does use a DST-prone timezone, don’t schedule jobs during the transition.
PS. My servers are on Hetzner. Hetzner images default to Europe/Berlin, I noticed too late…
This made me curious to see how systemd timers do it, and they simply don’t
Does this mean all other UNIX-based OSes (or at least Vixie-cron using distros) don’t do this properly (e.g., running the same job twice when time jumps backwards)? That would be pretty messed up.
The Debian patch says it’s originally from OpenBSD, so OpenBSD is likely similar. I haven’t experimented with other OSes yet.
Soo many patches in that repo, and they never went upstream of the whole source became upstream ?!
the upstream repo looks more nostalgic than really active: https://github.com/vixie/cron
It looks to me that a community fork to upstream all these things to is better than having all these patches maintained in various distributions.
The timing on lobste.rs is sometimes irritating. Just yesterday someone opened an issue somewhere else about their system running without a cmos battery, so when they start again their system gets a new time from the internet, and in that second the timer library fires for some hundreds of times.