Cron job

From Free Hosting Wiki
Revision as of 07:29, 6 March 2012 by Misson (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Jump to: navigation, search

A cron job is a way of periodically executing a command line program. Cron jobs are executed by the cron daemon. cron reads jobs from a cron table (also known as a crontab), which is a text file that holds one job per line. Cron jobs can be created using cPanel.



On free hosting, cron jobs are only allowed to run once every five minutes for each user. This limit includes all of a user's cron jobs. For example, if a user has two jobs, each can only run on average every ten minutes.

crontab Format

Blank lines and leading spaces and tabs are ignored. Lines whose first non-space character is a pound-sign (#) are comments, and are ignored. Note that comments are not allowed on the same line as cron commands, since they will be taken to be part of the command.

Each line has five time and date fields followed by a command. The fields are separated by whitespace; the amount doesn't matter. As a result, the first five field cannot have any whitespace within the field. Commands are executed by cron when the minute, hour, and month of year fields match the current time, and when at least one of the two day fields (day of month, or day of week) matches the current time*. The time and date fields are:

fieldallowed values
day of month1-31
month1-12 (or names, see below)
day of week0-7 (0 or 7 is Sun, or use names)

A field may be an asterisk (*), which always stands for "first-last" (meaning all values for that field).

Ranges of numbers are allowed. Ranges are two numbers separated with a hyphen. The specified range is inclusive. For example, 8-11 for an "hours" entry specifies execution at hours 8, 9, 10 and 11.Lists are allowed. A list is a set of numbers (or ranges) separated by commas. Examples: "1,2,5,9", "0-4,8-12".Step values can be used in conjunction with ranges. Following a range with "/<number>" specifies skips of the number's value through the range. For example, "0-23/2" can be used in the hours field to specify command execution every other hour (the alternative in the V7 standard is "0,2,4,6,8,10,12,14,16,18,20,22"). Steps are also permitted after an asterisk, so if you want to say "every two hours", just use "*/2".

Names can also be used for the ``month and ``day of week fields. Use the first three letters of the particular day or month (case does not matter). Ranges or lists of names are not allowed.The "sixth" field (the rest of the line) specifies the command to be run. The entire command portion of the line, up to a newline or % character, will be executed by /bin/sh. Percent-signs (%) in the command, unless escaped with backslash (\), will be changed into newline characters, and all data after the first % will be sent to the command as standard input.

For the command to be a valid, the first item must be a valid executable file. The PATH environment variable for the cron process is limited, so you generally need to include the full path to the executable. If the job is to execute a script, the executable should be the interpreter, not the script. For example, to execute a PHP script named "foo.php" that resides in your home directory, use "/usr/local/bin/php $HOME/foo.php"

*Note: The day of a command's execution can be specified by two fields -- day of month, and day of week. If both fields are restricted (ie, are not *), the command will be run when either field matches the current time. For example, "30 4 1,15 * 5" would cause a command to be run at 4:30 am on the 1st and 15th of each month, plus every Friday.

Environment Variables

With direct access to your crontab file, you could set environment variables in addition to scheduling cron jobs. However, unless you have a VPS account, you're limited to the cPanel interface. From there, you can set environment variables for individual jobs by placing them before the command. If a value contains spaces, it must be enclosed in quotes, otherwise the command line parser will take the first space as the end of the assignment and (in the absence of an equals sign) the next non-space as the start of a command.

# sets FOO and LIST environment variables
FOO=BAR LIST='1 2 3' /path/to/command
# Without the quotes, "LIST=1" and "2" will be taken as separate tokens

Not many environment variables are set by default. $HOME and $MAILTO are likely the most useful, as the former can be used in the command line (see samples below) and the latter could be used if sending reports within the scheduled program. $PATH is also important, though not used explicitly. Here's a sample of what you might find.

([0]="3" [1]="2" [2]="25" [3]="1" [4]="release" [5]="x86_64-redhat-linux-gnu")
" \t\n"
(cron email from cPanel)
'+ '

PHP Scripts


On the X10 servers, the PHP command line binary is located at "/usr/bin/php" and "/usr/local/bin/php".


PHP was originally designed as an HTML templating language. Its capabilities have been expanded quite a bit over the years, but is still primarily used to handle web requests. As such, it's not the best language to use for command line scripts (Perl and Python are better choices), but it can be used in a pinch.

PHP run from the command line is handled differently than when it's run to service HTTP requests. In the latter case, the web server provides all sorts of information via the superglobals as per the CGI spec. When run from the command line, there is no web server to provide these details; indeed, much of the information doesn't even make sense in the context of command line programs (consider $_SERVER['REMOTE_ADDR'], $_SERVER['HTTP_USER_AGENT'], along with the rest of the HTTP header values, and the entire $_POST array). For this reason (along with others), it's best to separate command-line scripts from web scripts. Any code (functions, classes &c) that is used by both command line and web scripts can be kept in library scripts and included as necessary.

Not every file can be executed directly. If you were to take a text file at random from your computer, for example, you wouldn't expect to be able to run it. Command line programs generally take two forms: binaries that can be executed directly by the computer, and scripts that need to be interpreted by a binary. For the latter to work under Linux (the OS used on the X10 servers), they must begin with a shebang line, which consists of the text "#!" (the shebang), followed by the path to a binary that can execute the script, along with any options to pass to the binary. When a file is executed under Linux, it examines the first few bytes to tell what type of file it is, which determines how it's run. The shebang characters actually form a magic number that signifies the file should be passed to another file, given in the bytes following the shebang. This means for a PHP script to be directly executable, it must begin:

/* rest of script follows */

Since the shebang line is outside the PHP tag, it would normally get printed directly. If you access a command line script as a web page, this is what you'll see. The command line PHP binary can recognize when the first line of a PHP script is a shebang line and will ignore it. This is another reason to keep command line and web PHP scripts separate. As an alternative to the shebang line, don't run PHP scripts directly. Instead, include the PHP binary in the cron job and pass the script to run as one of the parameters.

As with many command line programs, the CLI version of PHP supports numerous command line options that change its run-time behavior. -d, for example, can be used to set ini directives. All options start with a hyphen. For the full list of options, see the PHP manual section on command line options. Anything on the command line after the PHP script name is placed in the $argv array. Use a double hyphen to separate options for the PHP binary and options for the script to make sure the script gets the options it's supposed to get:

/usr/local/bin/php -d foo=bar -q $HOME/path/to/script.php -- -a -b -c 


The e-mail feature in cPanel is currently disabled. If you want to log output from a cron job, either capture its output in a file (see examples below) or have the command itself handle logging by (e.g.) writing to a file or sending an e-mail.


Run 'foo.php' every Sunday, capturing output:

* * * * Sun /usr/local/bin/php $HOME/foo.php >> $HOME/log/foo.txt 2>&1

Run 'email.php' every day at midnight:

0 0 * * * /usr/local/bin/php $HOME/email.php

Run job1 every 10 minutes (except on the hour), job2 on the hour (except at midnight), job3 at midnight (except Monday) and job4 at midnight on Monday, capturing output:

10-50/10 *    * * *     $HOME/bin/job1 >> $HOME/log/jobs.txt 2>&1
0        1-23 * * *     $HOME/bin/job2 >> $HOME/log/jobs.txt 2>&1
0        0    * * 0,2-6 $HOME/bin/job3 >> $HOME/log/jobs.txt 2>&1
0        0    * * Mon   $HOME/bin/job4 >> $HOME/log/jobs.txt 2>&1

With 4 jobs that are to run every 5, 10, 15 and hourly, there will be many conflicts when multiple jobs run at the same time. Resolve this conflict by skipping a more frequent job when it would run at the same time as a less frequent job, which is easily done using commas to specify a set of run times:

5,25,35,55  * * * * $HOME/periodic/5m
10,20,40,50 * * * * $HOME/periodic/10m
15,30,45    * * * * $HOME/periodic/15m
0           * * * * $HOME/periodic/hourly

Or, just to obfuscate things a bit:

5/30,25/30  * * * * $HOME/periodic/5m
10/30,20/30 * * * * $HOME/periodic/10m
15-45/15    * * * * $HOME/periodic/15m
0           * * * * $HOME/periodic/hourly

External links

  • Wikipedia entry on cron
Personal tools