For such a critical system component, why is cron so devilishly stupid? 1) Hour and minute are backwards. I get bitten by this all the time, particularly on days when I had to get up too early to do software patching on a few dozen servers. 2) For that matter, all the other time fields are backwards too. Must have been written by an American. In the rest of the sane world, we start with least significant and then work out way up to most significant (or the reverse). Not go backwards and forward all over the shop. 3) All the time fields are ANDed. Except day and month. So debian needs this hack to run mdadm check on first sunday of the month: 57 0 * * 0 root if [ -x /usr/share/mdadm/checkarray ] && [ $(date +\%d) -le 7 ]; then /usr/share/mdadm/checkarray --cron --all --idle --quiet; fi instead of this: 57 0 1-7 * 0 root if [ -x /usr/share/mdadm/checkarray ] ; then /usr/share/mdadm/checkarray --cron --all --idle --quiet; fi You have to go to extra effort to make it this bad. Why would you possibly want the date field to be ORed with the day of week? Was vixie on powerful drugs at the time? 4) "cron reads the crontab file(s) every minute to see whether there have been changes. Therefore, any change to its schedule will take effect within one minute." No, it reads the cron files every minute, and then applies the new schedule the next minute? Ie, there's always a minimum of a 1 minute delay to a schedule update, and up to 2 minutes. Why? Why would it not just read the new times, and if there's an entry for the current minute, act upon it instead of checking whether there was a job due the next minute to apply in the next minute? Again, this requires special kind of bodgery to get wrong. Unfortunately, this crappy behaviour is well embedded in the standard operation of cron, and can't be changed because it would break the expected broken behaviour. Can we define a new standard is-not-quite-cron? This rant brought to you by yet another "/tmp/crontab.uPh6Gi/crontab":24: bad hour errors in crontab file, can't install. Do you want to retry the same edit? (y/n)" -- Tim Connors
On Tue, 14 Feb 2012, Jason White wrote:
Tim Connors <tconnors@rather.puzzling.org> wrote:
Can we define a new standard is-not-quite-cron?
Systemd developers are planning to support Cron-like scheduling if that helps you.
Yeah, as soon as I pressed "send", I realised I should have clarified: "and not systemd!". I prefer my software without tentacles. http://upstart.ubuntu.com/wiki/ReplaceCron "Cron compatibility A new cron event on cron MINUTE=mm HOUR=hh DOM=dd MONTH=mm DOW=w This allows a script to use normal cron times because of pattern matching" I mean, *why*? Why would you even consider highlighting that as a feature? If you're wanting to plug it into the place of cron, then that format helps no one, because it looks nothing like cron except the ordering of the fields (you also don't edit cron fields through the commandline). Of course things that look like the standard way you set environment variables (<named field>=<value>) doesn't depend on order. There's no need to highlight that as a "feature", especially when the particular feature in question is so crufty. I also don't like my cron replacement being so dependant upon the init replacement[1] and requiring a special bus that isn't allowed to be restarted lest it crash the system (hello DBUS funk!). [1] Anyone else think that parallel boot is so much more pain than it's worth? eg, debian bug #634215 -- Tim Connors
On Tue, Feb 14, 2012 at 02:20:13PM +1100, Jason White wrote:
Tim Connors <tconnors@rather.puzzling.org> wrote:
Can we define a new standard is-not-quite-cron?
Systemd developers are planning to support Cron-like scheduling if that helps you.
systemd doesn't help anyone. :) craig ps: systemd is the antithesis of unix software. a jack-of-all-trades, master-of-none rather than a modular collection of single-purpose programs intended to be the best at what they do (or replacable with something better). systemd, like the gnome shell, is intended to turn linux into a second-rate imitation of a Mac or an iphone, something that will be worse than useless to both Mac users and linux/unix users. -- craig sanders <cas@taz.net.au> BOFH excuse #392: It's union rules. There's nothing we can do about it. Sorry.
Jason White wrote:
Tim Connors <tconnors@rather.puzzling.org> wrote:
Can we define a new standard is-not-quite-cron?
Systemd developers are planning to support Cron-like scheduling if that helps you.
Sigh. I was just about to suggest that Lennart would be happy to introduce All New! perfectly executed fuckups if you asked him nicely.
Hi Tim, maybe you do not have to reinvent the wheel. Quoting "Tim Connors" <tconnors@rather.puzzling.org>:
For such a critical system component, why is cron so devilishly stupid?
1)
Hour and minute are backwards. I get bitten by this all the time, particularly on days when I had to get up too early to do software patching on a few dozen servers.
2)
For that matter, all the other time fields are backwards too. Must have been written by an American. In the rest of the sane world, we start with least significant and then work out way up to most significant (or the reverse). Not go backwards and forward all over the shop.
There are variables like MAIL or PATH. It would be possible to define a "ORDER" variable that modifies your order. E.g. ORDER="DAY MONTH HOUR DAY WEEKDAY" or whatever you wish. After your entry you could make an unset ORDER so that following entries (e.g. added by packets) aren't affected.
3)
All the time fields are ANDed. Except day and month. So debian needs this hack to run mdadm check on first sunday of the month:
57 0 * * 0 root if [ -x /usr/share/mdadm/checkarray ] && [ $(date +\%d) -le 7 ]; then /usr/share/mdadm/checkarray --cron --all --idle --quiet; fi instead of this: 57 0 1-7 * 0 root if [ -x /usr/share/mdadm/checkarray ] ; then /usr/share/mdadm/checkarray --cron --all --idle --quiet; fi
Well, the first Sunday of the month is a bit trickier. Feel free to make it also configurable (WEEKDAY_AND=1 or so). But the existing one is so "embedded" in my way of reading the crontab that it may confuse me first. These changes should be quite trivial to integrate in the existing cron.
You have to go to extra effort to make it this bad. Why would you possibly want the date field to be ORed with the day of week? Was vixie on powerful drugs at the time?
4)
"cron reads the crontab file(s) every minute to see whether there have been changes. Therefore, any change to its schedule will take effect within one minute."
No, it reads the cron files every minute, and then applies the new schedule the next minute? Ie, there's always a minimum of a 1 minute delay to a schedule update, and up to 2 minutes. Why? Why would it not just read the new times, and if there's an entry for the current minute, act upon it instead of checking whether there was a job due the next minute to apply in the next minute? Again, this requires special kind of bodgery to get wrong.
This is more of an implementation detail as design. Opposite to other daemons, cron can be configured by every user (everyone can have a crontab). In most other cases the admin can send a SIGHUP to the demon, it does not work here (not too mention that "average Joe" may wonder what it means to send a SIGHUP when he changed a crontab). A "smart" filesystem system can trigger this SIHUP if the crontab directory changes. But not all fs providing triggers. To check that all can take time, and to avoid too much piling up, it reads a config and changes the "internal" one, while it runs all existing one immediately in parallel. I don't know whether a one or two minute delay is such an issue. It hasn't been for me, until now. And for the systemd story: a system that runs a daemon to get the hostname (hostnamed), is beyond my intellectual capabilities. Regards Peter
participants (5)
-
Craig Sanders -
Jason White -
Peter Ross -
Tim Connors -
Trent W. Buck