cron

[Tim Connors]

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)"

[Jason White]

Post by Tim Connors
Can we define a new standard is-not-quite-cron?

Systemd developers are planning to support Cron-like scheduling if that helps
you.

[Tim Connors]

Post by Jason White

Post by Tim Connors
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

[Craig Sanders]

Post by Jason White

Post by Tim Connors
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.

[Trent W. Buck]

Post by Jason White

Post by Tim Connors
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.

[Peter Ross]

Hi Tim,

maybe you do not have to reinvent the wheel.

Post by Tim Connors
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.

Post by Tim Connors
3)
All the time fields are ANDed. Except day and month. So debian needs
57 0 * * 0 root if [ -x /usr/share/mdadm/checkarray ] && [ $(date
+\%d) -le 7 ]; then /usr/share/mdadm/checkarray --cron --all --idle
--quiet; fi
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.

Post by Tim Connors
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