Looking at cron

Having a sysadmin background, I am fairly familiar with cron. I’m amazed at how many companies set up cron jobs and assume everything will just work. If root mail is not checked (or forwarded to someone who actually reads it), a cron job could fail and you would never know.

Having an automated task fail silently is a Bad Thing (TM). I take commands which should have no output normally (such as mysqldump > dumpfile.sql and mysql < maintenance.sql) and pipe the output into a script called mailif. The script will e-mail a specified recipient if standard input is not blank.

In plain English, if the automated task has ANY output or error code, it e-mails me.

One of my current tasks is going through all the database maintenance scripts and making sure it e-mails me if there's an error.

Standard cron entries have 6 fields:
minute 0-59
hour 0-23
day of the month 1-31
month 1-12
day of the week 0-7
command (the rest of the line)

A wildcard, *, is permitted. So you can easily have a command (or a script) run every minute, every hour, every day, every month, or every Monday. You can also do more complex routines like run a command when there's a "Friday the 13th during October."

So a backup script to dump tables in a database every day at 6 am would have the following crontab entry:
0 6 * * * mysqldump --all-databases > /var/log/mysql/dump/backup.sql | /usr/local/bin/mailif -t user@domain.com "output of mysqldump"

If the mysqldump fails, cron will send user@domain.com an e-mail with the subject of “output of mysqldump” and the body will be the output.

One thing I learned looking at the cron entries that were setup by someone else is that to set up a routine occuring every ten minutes, the minute field has */10 in it. Fascinating, given that I’d always written out a comma-separated list 0,10,20,30,40,50.

Having a sysadmin background, I am fairly familiar with cron. I’m amazed at how many companies set up cron jobs and assume everything will just work. If root mail is not checked (or forwarded to someone who actually reads it), a cron job could fail and you would never know.

Having an automated task fail silently is a Bad Thing (TM). I take commands which should have no output normally (such as mysqldump > dumpfile.sql and mysql < maintenance.sql) and pipe the output into a script called mailif. The script will e-mail a specified recipient if standard input is not blank.

In plain English, if the automated task has ANY output or error code, it e-mails me.

One of my current tasks is going through all the database maintenance scripts and making sure it e-mails me if there's an error.

Standard cron entries have 6 fields:
minute 0-59
hour 0-23
day of the month 1-31
month 1-12
day of the week 0-7
command (the rest of the line)

A wildcard, *, is permitted. So you can easily have a command (or a script) run every minute, every hour, every day, every month, or every Monday. You can also do more complex routines like run a command when there's a "Friday the 13th during October."

So a backup script to dump tables in a database every day at 6 am would have the following crontab entry:
0 6 * * * mysqldump --all-databases > /var/log/mysql/dump/backup.sql | /usr/local/bin/mailif -t user@domain.com "output of mysqldump"

If the mysqldump fails, cron will send user@domain.com an e-mail with the subject of “output of mysqldump” and the body will be the output.

One thing I learned looking at the cron entries that were setup by someone else is that to set up a routine occuring every ten minutes, the minute field has */10 in it. Fascinating, given that I’d always written out a comma-separated list 0,10,20,30,40,50.

Comments are closed.