JDPFu.com 2025

Put a Reminder Comment with the Crontab Format in Every Crontab

In the top of every crontab, place a simple comment with the crontab format. You’ll never need to remember the format again.

# m h  dom mon dow   command

The link above to the cron tutor has a fancy description of each field. You can also place this into your crontab, just be certain to comment out all the extra lines.

Set Your EDITOR to Control the Editor used for crontabs.

In your .bashrc, .profile, or similar shell startup file, enter the following if you like vi (and why would anyone use any other editor?):

export EDITOR=vi
or
export EDITOR=emacs
or
export EDITOR=jot

You can also set it in a shell, then run

crontab -e

will edit your personal crontab.

sudo crontab -e

will edit the crontab for root. Root will use whatever EDITOR variable is set which may not be what you like.

Use cron to Backup Your Crontab automatically.

If we are performing limited backups, we will probably capture important files in our HOME directories, but some times we forget there are other important files, like the crontab. Don’t forget that your personal crontab needs to be backed up too.

51 1  * * *   crontab -l > $HOME/crontab.backup

It will be overwritten daily. You may want to place the backup file into a different location or retain more than a single copy over time by adding a date-stamp to the output file.

51 1  * * *  crontab -l > $HOME/crontab.backup.`date “+%a”`

This command will retain 7 days of crontab files and overwrite the current day.

Stop cron from Emailing Results

Sometimes you want cron to email the results of the command. This assumes that you’ve setup an MTA to send email to the desired email account and probably setup an email alias to forward the cron output to a real mail server. Often, cron output can become huge and not that important for you to see all the time.

Note the /dev/null redirection in the cmd below. Both stdout and stderr are redirected there. That will prevent the output from being emailed.

41 * * * * /raid/scripts/lshw-for-all.sh  > /dev/null 2>&1

If you don’t have your system setup to forward email or you don’t prevent cron from attempting to email, then the mail will still be send, just to a local account. Over time, if you forget to clean out the /var/spool/mail folder, the file system will fill up. That is bad.

Set Your Environment Variables in a script

Environment variables in cron are not set the same as in a fully interactive shell. This is good and bad. Scripts run from cron often fail since a personalized PATH or LIBPATH or LD_LIBRARY_PATH or JAVA_HOME variables don’t get picked up by cron run jobs. Cron scripts will get the global environment which may be good enough.

If you’ve ever seen production-level scripts, you may see that PATH is set and that all program references are fully qualified and do not trust the PATH at all. This is a good practice for all scripts, since you can never be certain what environment everyone running the script will bring.

Here is a sample root crontab pulled from a running machine.

$ sudo crontab -l

\# m h  dom mon dow   command

\/1 * * * * /usr/local/sysusage/bin/sysusage > /dev/null 2>&1

\/5 * * * * /usr/local/sysusage/bin/sysusagegraph > /dev/null 2>&1  

Sorry – the blog software is screwing with the entries.

It is a minimal root crontab for all my servers. Most have just a few more lines to handle backups.