[linux-elitists] A better cron: large production environments
Karsten M. Self
karsten at linuxmafia.com
Fri May 7 17:09:22 PDT 2010
I'm kicking ideas around for a better cron system (or framework for the
existing system) which might help address some of the shortcomings of
cron as are being experienced now, particularly in notification and
General environment is a largish production server installation. We
happen to be in the web space, but any large multi-host infrastructure
with copious old, poorly-understood, and fragile cron jobs might
- Reduce chatter. Excessive messages, whether null, extraordinarily
long, just plain confusing, or that don't need to exist at all.
- Simplify and standardize cron job mail output to allow for more
efficient mail filtering, assessment, evaluation, parsing, etc.
- Instrumentability for existing monitoring systems. The ability to
plug in alerts for Nagios or other monitoring tools for failed jobs,
etc., would be useful.
- Other than informational cron messages (e.g.: "this is the state of
your system today), keeping status, warning, and error messages
*out* of mail (other than a very brief synopsis), instead logging
this through other facilities (e.g.: syslog, application or
job-level logging, particularly enabling log rotation through toosl
such as logrotate).
- Variable levels of email notification: standard operational
messages to Those Who Should Know, status or informational messages
to target client users (or email addresses), problem alerts to
staff/management who should know, etc. Send mail to those who
should receive it, not to those who shouldn't. Don't clobber legacy
(<coff>Exchange</coff>) mail systems with absurdly low per-user
mailbox size restrictions.
- Concise job execution status:
- Failed to start
- Failed to complete
- Output/context based error, warning, or info level
- Other ... ??
(I'm basing some of this on a QA framework tool I used a few years
back based mostly on some pretty simple POSIX / shell tool
conventions, I think originally devleped at CMU, though I'm
pulling a complete blank at the moment).
- Logging of job output (stdout, stderr, possibly other), preferably
via syslog (e.g.: logger(1)), to separate notification frm debug.
- Tailoring of output verbosity (for both logging and emails).
- Web / Intranet access to job log(s) for info, ouput, error,
debugging, etc, preferably with a URL posted to mail for further
None of this is rocket science, all of it's pretty trivial stuff, I'm
mostly curious as to whether or not there's something that exists which
fits this bill, and/or if there's interest in seeing a general tool
Karsten M. Self <karsten at linuxmafia.com> http://linuxmafia.com/~karsten
What part of "gestalt" don't you understand?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the linux-elitists