Crontab – best practices

Crons can get us to impossible situations. They can get very difficult to trace where things can go wrong. Here I’m trying to outline the process of setting up crons and logging the activities so as to help avoid chaos.

To start editing the crontab

$ sudo nano /etc/crontab

Another way of editing the crontab is per-user crontab

$ crontab -e

First when setting up any crons on your server, ensure that they are grouped by the various sites you need them that are hosted on the server. Comment them out clearly and have all the team members to add or modify them in the appropriate sections.

###
# Crons for the site myhardworkingsite.com
###

Secondly, make sure you keep a copy of the template that’s found on top of the /etc/crontab under each section for quick reference.

# m h dom mon dow user  command

Ensure that the script is run via cron by setting the time close to the current time on the server

$ date

You can verify this by listing the running programs

$ ps aux | grep <the_script_file_name>

or by listing it from the cron log as in

$ sudo tail -100 /var/log/cron.log | grep <the_script_file_name>

Syntax Errors
To identify whether the crontab is read correctly, run the following commands – it could be bad username or bad minute or some such thing, check the recently added one, or comment and save to see others are running.

$ sudo cat /var/log/cron.log | grep bad
 
Jan 1 00:07:01 xxxxxxxxxx cron[17836]: Error: bad username; while reading /etc/crontab
 
# or
$ sudo cat /var/log/cron.log | grep Error:
Jan 1 00:08:01 xxxxxxxxxx cron[17836]: Error: bad username; while reading /etc/crontab

Pitfalls – the most common errors

Number of stars: It is very easy to get carried away in leaving an additional star on the cron string, more specifically when it is copy pasted from another one.

Missing username: When moving from cPanel based servers to VPS, we tend to paste the string from there which doesn’t have the username parameter.

Midnight: Very often, users tend to setup crons at midnight, there could be others running on shared resources cranking up the server load. Better to be safe and set the “once-in-a-day” cron to a jagged time like 2:32am or some such stuff.

Cron Log – setting up if it doesn’t exist

By default, logging is done by the syslog daemon and configured in /etc/rsyslog.conf. It gets difficult to monitor this since lot of things are written to syslog. To have the cron logs exclusive to /var/log/cron.log, do the following

Login a root user

$ sudo -s

Check and enable cron logging

$ nano /etc/rsyslog.d/50-default.conf

Add the following line: cron.* look for one that is commented out and uncomment it and restart the syslog daemon. You probably need to create the cron logfile too before restarting the syslog daemon.

# Create a cron log file, this step wasn't required for 14.04
$ touch /var/log/cron
# Make changes to the log file
$ nano /etc/rsyslog.d/50-default.conf
 
# and then
$ service rsyslog restart

References

http://www.linuxquestions.org/questions/programming-9/crontab-log-does-not-exist-552809/