cron

The cron daemon (a program that runs continuously and exists for the purpose of handling periodic service requests that a computer system expects to receive) is where all timed events are handled. Cron commands are usually referred to as "jobs." For me, cron jobs are a totally essential tool. I use them to run scripts at regularly scheduled intervals. For example, I send out email newsletters every Wednesday at 10:30 and also the first Thursday of each month at 11:30. I also run a bounce detection script once a day to handle returns from those newsletters. Other uses include regular database backups, nightly statistics, etc. With a little imagination, you will think of unique needs for your own cron jobs. Additionally, many open source programs require the use of one or more cron jobs.

The configuration files used to control the operation of cron are called crontab files or cron tables. These files contain information about the time, date and command to execute. Different versions of UNIX store cron and support files in different locations. You will want to check with your webhost to find out the location for your account. Crontab files are typically named after user accounts, but I have seen systems that allow you to create a crontab with any name. Since you can put multiple timed events in one crontab file, that isn’t really necessary, so just stick with the default your webhost uses.

The crontab command

Generally, there are two ways to set cron jobs for your site. Your webhost control panel may offer a graphical interface to the crontab file for your account. Virtual Private Servers (VPS) and dedicated servers will usually also offer access to your cron directory (via file manager, FTP and/or secure shell). Using a control panel should be straightforward. If you use direct access to the crontab file however, it is important to know that you can’t just edit a crontab file, stick it in your cron directory and expect it to run. Instead you must use the crontab command, which is used to edit, list, create or remove a crontab file for a user.

Using the crontab command without options executes whatever information you entered at the keyboard. This makes it easy to remove the existing crontab by mistake. If the crontab is run without options it should be exited with a "Control C" so that the existing crontab is unmodified. Entering a "Control D" will cause the current users’ crontab to be replaced with no information, thereby erasing the existing crontab. To avoid this, I usually keep my crontab file on my local PC and transfer it the cron directory. Then, from the command line I just type crontab <filename>.

The list option, crontab -l, displays the contents of the current user’s crontab file, though I notice this isn’t supported by all hosting plans. The remove option, crontab -r, should empty the contents of the current user’s crontab file.

Crontab Format

Each line or entry in a crontab file represents either an environment variable setting, a cron table entry (job), or a comment (beginning with the # symbol). Each job line has six fields which are separated by space characters. The first five fields tell the cron daemon when to execute the command, which is contained in the sixth field.

FIELD VALUE
————————————————————————
Minute 00 to 59
Hour 00 to 23 (military time)
Day 1 to 31
Month 1 to 12
Weekday 0 to 6 (0=Sunday)

The first five fields can also use any one of the following formats.

• An asterisk character (*) to match all values.
• A single integer that matches that exact value.
• A comma separated list of integers, like 1,3,5 to match one of the listed values.
• A range of integers separated by a dash, like 4-6, to match the values within the range.
• Step values can be represented as a sequence, i.e. 0-59/15, 1-31/3, or */2.

Here are sample entries along with a short explanation of when the operation will be performed.

• 0 * * * * echo "HOURLY TEST" 2>&1 /www/htdocs/cron_output.txt
  This entry sends the string HOURLY TEST to a file titled cron_output.txt at the start of every hour on every day of every month.

• */15 * * * * echo "15MIN TEST" 2>&1 /www/htdocs/cron_output.txt
  This entry sends the string 15MIN TEST to a file titled cron_output.txt every fifteen minutes on every hour on every day of every month.

• 0-30/10 * * * * echo "10MIN TEST" 2>&1 /www/htdocs/cron_output.txt
  This entry sends the string 10MIN TEST to a file titled cron_output.txt every ten minutes of the first half hour on every day of every month.

• 10 11 * * * echo "DAILY TEST" 2>&1 /www/htdocs/cron_output.txt
  This entry sends the string DAILY TEST to a file titled cron_output.txt at 11:10 a.m. every day of every month.

• 10 11 15 * * echo "MONTHLY TEST" 2>&1 /www/htdocs/cron_output.txt
  This entry sends the string MONTHLY TEST to a file titled cron_output.txt at 11:10 a.m. on the 15th day of every month.

• 10 11 15 1 * echo "JANUARY TEST" 2>&1 /www/htdocs/cron_output.txt
  This entry sends the string JANUARY TEST to a file titled cron_output.txt at 11:10 a.m. every January 15th.

• 10,40 * * * * /adm/checkdaemon 2>&1 | /bin/mail -s "CRON:Check" root
  This entry runs the command checkdaemon and mails the output of the command to root. The command is run 10 and 40 minutes after the hour on every day of every month.

Running PHP Scripts

If you want to run a PHP script, the method you use will depend on your webhost environment. One big consideration is whether your PHP installation is CGI or CLI (Apache module). You can see which setup you have by referencing the phpinfo output. Look for Server API (4th item from the top). If it says "CGI", you have PHP compiled as CGI, if it reads "Apache", you have it running as CLI. In any event, without going into boring details which I am not terribly knowledgeable of, just know that there are two basic ways to call a PHP script:

• Call the script directly by referencing the PHP path followed by the PHP script:
  * * * * * php /path/to/your/phpscript.php > /dev/null
  
  Note: to be safe, you should add a line containing contain your server’s PHP executable location to the top of any script you wish to call from cron. For example:
  #!/usr/local/bin/php –q
  
  Finally, make sure your script has the proper permissions set to be executable (chmod 755 should do it).

• Call the script via a text browser which is installed by most webhosts. The most common are lynx and GET. Below is an example using lynx:
  * * * * * lynx -dump http://www.domain.com/phpscript.php > /dev/null
  
  Note: to be safe, you should specify the complete URL rather than using a relative path.

I believe the first option (directly calling the script) is most suitable for CGI implementations but you should test to see for yourself. I believe the second method should work regardless, assuming you have access to lynx.

Environment Variables

Several environment variables are set up automatically by the cron daemon, including SHELL, LOGNAME, USER, and HOME. In addition to these, there is a special MAILTO environment variable. Any output generated by your cron jobs will be sent to the address specified by MAILTO. If it is not specified it will be sent to the owner of the crontab. If MAILTO is defined as an empty string then no mail will be sent.
MAILTO = ""

Like this content? Why not share it?