Runmaint - A Cron Wrapper Script

The script runmaint is a wrapper for cronjobs (and in principle other batch jobs) which:

• greatly simplifies the crontab entry
• ensures the job runs with a fuller environment than is usually present in batch mode
• delivers the output (if any) as email with a meaningful subject line, and does not email if there is no output
• allows regular jobs to each have their own shell script, readily edited and meaningfully named
• allows relatively flexible scheduling and cascading of dependent jobs
• allows you to amend, add and delete jobs from any machine which can see the maintenance directory instead of having to be on the target machine manually editing the crontab

Setup

1. Install runmaint (and the associated scripts mailif, execif and mailsubj) somewhere sensible. On my systems this is /usr/local/script but it can be anywhere central or equally well your own personal bin directory if you lack sysadmin rights.
2. Make the directory for the scripts. For root this is /usr/local/etc/maint with a subdirectory called scripts. For other users this is the directory $HOME/.maint and there is no scripts subdirectory.
3. Put a suitable line in the crontab for the user.
   The common example is nightly maintenance This would imply a line like:

   0 0 * * * exec /usr/local/script/runmaint daily

   Another common example is hourly maintenance such as running regular reports. This would imply a line like:

   0 * * * * exec /usr/local/script/runmaint hourly

   Both of these imply their less frequent jobs (daily, monthly, etc); those jobs are checked for based on the noted frequency of the base job. An hourly job will, at midnight, run daily jobs, a daily job on Monday will run weekly jobs, a daily job on the first of the month will run monthly jobs, a daily job on the first of January will run yearly jobs.

   Further, the less frequent jobs are run after the more frequent jobs, so you are guarrenteed that an unusually long daily job will not overrun the weekly tidyup which expects it to have finished, and that the weekly tidyup will run immediately after the daily job rather than some guestimated "suffient time later".
   You can see the implementation of this in the case statement at the bottom of the script.

4. Construct a Bourne shell script called env in the maintenance directory (/usr/local/etc/maint for root $HOME/.maint for other users).
   It should set whatever envionment setting you consider sufficient for normal work. I like it to be the same as my normal shell environment. Therefore, assuming they weren't authored by idiots, a script sourcing /etc/profile and then $HOME/.profile should suffice, viz:

   . /etc/profile
   . $HOME/.profile

   .
5. Construct scripts for your jobs in the maintenance scripts directory (/usr/local/etc/maint/scripts for root $HOME/.maint for other users). See the section on Script Naming.
   You can also look at my runmaint scripts as an example of what they look like.
   These scripts
   • must be in Bourne shell, so if you have scripts in other languages (sed, awk, perl or even -- gaak! -- csh) you'll have to invoke them from within the main script
   • can assume your typical environment (courtesy of the setup file you made earlier) so no silly mucking around with full pathnames for commands need be done
   • can expect the following environment variables available:

     $RunMaint	The path of the runmaint command, for invocation of subsidiary scripts which are expected to have their output (if any) delivered in separate email.
     $MaintScripts	The path of the maintenance scripts directory.
     $MaintDir	The path of the maintenance directory (one up from $MaintScripts for root, the same as $MaintScripts for other users). Normally you will want to use $MaintScripts but perhaps you will want to keep associated data files which aren't themselves scripts separate.
     $datestr and $wday, $mon, $mday, $hh, $mm, $ss, $tz, $year	$datestr is the output of the date command at the time of starting runmmaint; this be overridden with the -date option but you really shouldn't - the option is really there to preserve the notional "start of script" time for subsidiary runmmaints such as an implicitly weekly script run through the regular invocation of the daily script. The $wday, $mon, $mday, $hh, $mm, $ss, $tz and $year values are simply the broken out fields from this string. For example, the easy way to run something at 9am (as I do, to prefetch the web pages I read as daily news) is to examine $hh. Here's relevant code from my hourly script: # prefetch some news case $hh in 09) ... prefetch code here ... ;; esac

Script Naming

runmaint [-x] [-s subj] script [addresses...]

-s subj deliverys the output in email with the subject line subj instead of the default "runmaint@host script addresses".

addresses... is a space separated list of email addresses to which to delivery the output email. If not supplied the email is delivered to the invoking user.

script is the name of the script to run. runmaint will look for the scripts $MaintScripts/script and then $MaintScripts/script.$HOST and then $MaintScripts/script.$HOST@$SYSTEMID where $HOST is the short hostname of the current host and where $SYSTEMID is a name for the notional administrative domain in which the host resides. For example, at home I have $SYSTEMID set to "home" and at my ISP it's "zip" (www.zip.com.au). For example, by creating a single file called hourly.sid I can thus leave an hourly invocation of "hourly" in my crontabs and have actions run only on the host sid.

Also, as noted briefly above, is the script is called "hourly" then at midnight runmaint will also look for a "daily" script. When running "daily", on Monday it looks for a "weekly". When running "daily", on the first of the month it looks for a "monthly". When running "monthly", on the first of January it looks for a "yearly".