4

I'm currently confronted with a cron file that contains a dozen different applications' tasks--some have only one, some have lots. I'm trying to figure out a good way to organize and document these processes. Are there any conventions out there that I could emulate or am I stuck making something up?

warren
  • 18,369
  • 23
  • 84
  • 135
abeger
  • 471
  • 1
  • 4
  • 6

4 Answers4

8
#minute hour    mday    month   wday    who     command

## Acme Anvil Application
# clear logs every 5 minutes
*/5     *       *       *       *       root    /path/to/clear_logs
# monthly maintenance
30      5       1       *       *       root    /path/to/acme/maintenance

## Fabricam
# adjust timing
*/30    0-5     *       *       *       fab    /path/to/bin/fab_time

## Etc...
Chris S
  • 77,945
  • 11
  • 124
  • 216
5

If your system supports /etc/cron.d, you may also try breaking up the cron jobs into individual files, grouped by application.

root@linuxbox:/etc/cron.d# ls
sa-update  sysstat  vnstat

Note that the format of cron jobs in /etc/cron.d is a little different, in that you would put the user running the command in between the time fields and the command itself, e.g.,

root@linuxbox:/etc/cron.d# cat sa-update
### OPTIONAL: Spamassassin Rules Updates ###
#
# http://wiki.apache.org/spamassassin/RuleUpdates
# Highly recommended that you read the documentation before using this.
# ENABLE UPDATES AT YOUR OWN RISK.
#
# /var/log/sa-update.log contains a history log of sa-update runs

10 4 * * * root /usr/share/spamassassin/sa-update.cron 2>&1 | tee -a /var/log/sa-update.log
cjc
  • 24,916
  • 3
  • 51
  • 70
2

I would recommend ensuring that you have a comment at the end of your /etc/crontab file. Many implementations of cron won't fire off the last job in the file if it's not terminated with a Line Feed.

Debian Lenny being one of them.

Magellan
  • 4,451
  • 3
  • 30
  • 53
  • Interesting point. I edit my crontab with vim, which won't let me create a text file without a terminating newline unless I ask it very nicely. (Text files without a newline on the last line can cause a lot of problems.) – Keith Thompson Jan 19 '12 at 01:24
  • Sadly, not everyone uses Vi..... – Magellan Jan 19 '12 at 02:01
0

Great question. A few I have benefitted from:

0) Header comment

Add useful comments that will help you write entries, and reduce the chance of jobs not working as expected.

##------------------------------------------------------------
## (-) Characters to escape: %, $
## (-) Logs (on Linux) are located under /var/spool/mail/ (postfix needs to be installed)
##
## Min  Hour Day  Mon  Weekday
## *    *    *    *    *  command to be executed
## ┬    ┬    ┬    ┬    ┬
## │    │    │    │    └─  Weekday  (0=Sun .. 6=Sat)
## │    │    │    └──────  Month    (1..12)
## │    │    └───────────  Day      (1..31)
## │    └────────────────  Hour     (0..23)
## └─────────────────────  Minute   (0..59)
##
##------------------------------------------------------------

1) Order

Order your entries by time of the day (morning at the top, evening at bottom)

  • Rationale: it's easier to find the entry you wish to tweak.

2) PATH

  1. Explicitly set the PATH at the top of the file

    • Rationale: avoid "no such file or directory" errors (particularly if you need GNU versions of tools rather than Mac builtins!)
SHELL=/bin/zsh
PATH=/Volumes/apps/homebrew/Cellar/findutils/4.9.0/libexec/gnubin/:/Volumes/apps/homebrew/Cellar/coreutils/9.1/libexec/gnubin/:/Volumes/apps/homebrew/Cellar/findutils/4.9.0/libexec/gnubin/:/opt/local/bin/:

3) Limit sh /path/to/script.sh

Do not call scripts unless you really have to (it's better to call primitives directly in the crontab file)

  • Rationale: you can quickly find the entry responsible for certain behaviour

4) Backup crontab

Add the following entry (do the same in the root's crontab):

@weekly   crontab -l > ~/crontab.`whoami`.`date -I`.txt
  • Rationale: whenever you reinstall your OS, you can't easily rebuild your crontab.

5) | tee /tmp/cron_*log

Write the output of each entry to a log file on a ramdisk;

| tee /tmp/cron_*.log
| tee /tmp/cron_*.err.log

Rationale:

  • easier to find errors in crons (e.g. tail /tmp/cron_*.err.log)
  • junk log files don't accumulate beyond their useful life
  • no need to use the built in /var/mail/messages which gets bloated

6) tab after cron expression

  • Rationale: Some cron expressions will be longer than others, so starting all commands in the same character column will look neater (and help you compare different commands)
6  12 * * 5     echo "hello"
10 12 * * 1-5   echo "world"

Other

  • Start with a blank crontab every year (so that cruft gets weeded out periodically)
Sridhar Sarnobat
  • 103
  • 5