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