This isn't a problem with actual cron and crontab. It is a problem with the systemd-timers shim "crontab" which doesn't work the same in many corner cases and often has weird bugs.
This isn't a problem with actual cron and crontab. It is a problem with the systemd-timers shim "crontab" which doesn't work the same in many corner cases and often has weird bugs.
This post is literally about an issue observed in vixie-cron (as included in some distro c. 2013), not about any systemd implementation.
Exactly! The article makes the point that:
> until one of them achieves cron’s level of ubiquity, we have to live with cron at least some places and sometimes
systemd could arguably be described as close to (maybe behind, maybe ahead of since it's the default for the most popular Linux distros) cron's level of ubiquity, and doesn't have this bug as far as we know.
Which cron is actual cron? There are tons of implementations out there.
This post describes vixie-cron, not systemd-timers.
What do you consider "actual cron"? Because the post specifically says Vixie cron, which has been the basis for most versions of cron on Linux systems.
How does actual cron handle this situation?
"Not a problem" as in these only run these cron job once per day, irrespective of DST changes making a given "hour happen twice"?