The cost of OmniOS not having
Systems without /etc/cron.d just make my sysadmin life harder and more annoying. OmniOS, I'm looking at you.
For those people who have not encountered it, this is a Linux cron
feature where you can basically put additional crontab files in
/etc/cron.d. To many people this may sound like a minor feature;
let me assure you it is not.
Here is why it is an important feature: it makes adding, modifying,
or deleting your crontab entries as trivial as copying a file.
It is very easy to copy files (or create them). You can trivially
script it, there are tons of tools to do this for you in various
ways and from various sources (from
rsync on up), and it is very
easy to scale file copies up for a fleet of machines.
Managing crontab entries without this is either painfully manual,
involves attempts to do reliable automated file editing through
interfaces not designed for it, or requires you to basically build
your own custom equivalent of it and then treat the system crontab
file as an implementation detail inside your
This is a real cost and it matters for us.
/etc/cron.d, adding a new custom-scheduled service on some
or all of our fileservers would be trivial
and guaranteed to not perturb anything else. Especially, adding it
to all of them is no more work than adding it to one or two (and
may even be slightly less work). With current OmniOS cron, it is
dauntingly and discouragingly difficult. We have to log in to each
fileserver, run '
crontab -e' by hand, worry about an accidental
edit mistake damaging other things, and then update our fileserver
install instructions to account for the new crontab edits. Changed
your mind and need to revise just what your crontab entry is (eg
to change when it runs)? You get to do all that all over again.
The result is that we'll do a great deal to avoid having to update
OmniOS crontabs. I actually found myself thinking about how I would
invent my own job scheduling system in central shell scripts that
we already run out of cron, just because doing that seemed like
less work and less annoyance than slogging around to run '
-e' even once (and it probably wouldn't have been just once).
(Updates to the shell scripts et al are automatically distributed to our OmniOS machines, so they're 'change once centrally and we're done'.)
Note that it's important that
/etc/cron.d supports multiple files,
because that lets you separate each crontab entry (or logically
related chunk of entries) into an independently managed thing. If
it was only one single file, multiple separate things that all
wanted crontab entries would have to coordinate updates to the file.
This would get you back to all sorts of problems, like 'can I
reliably find or remove just my entries?' and 'are my entries
theoretically there?'. With
/etc/cron.d, all you need is for
people (and systems) to pick different filenames for their particular
entries. This generally happens naturally because you get to use
descriptive names for them.