The crontab is a scheduled job utility on *nix server.
To edit a cron schedule:
This will open the schedule file based on the EDITOR setting in your shell. VI is the most commonly used editor.
A cron schedule file can look like this:
*/10 * * * * php -f Ping.php > ping.out
MAILTO sets the address where the output of the cron goes. If you don't even want to receive it, set MAILTO="".
The first part of the second line is the schedule, and the second part is the command.
The job schedule is set in the following sequence:
- minute of the hour
- hour of the day
- day of the month
- month of the year
- day of the week
So in the example above:
- */10 means every 10 minute in an hour
- 2nd * means every hour of the day
- 3rd * means every day of the month
- 4th * means every month of the year
- 5th * means every day of the week
*/10 is the abbreviated way of saying "every 10 minutes in an hour".
Two other commonly used forms are comma separated values and a range using "-" (dash). For example:
0 9,12 * * * sets the job to run on top of the hour at 9am and 12 am, every day.
0 9,12 * * 1-5 sets the job to run on top of the hour at 9am and 12 am, every weekday.
The command can be anything executable, either be a unix command or a script. A good practice is to test the command from the console and make sure everything is setup environmentally and then put them into the crontab. Since I want to track the output the above example writes the output from the script to a file.
Sometimes I prefer the logging implemented in the script and do not want to receive it from cron email, I can set the it like this:
*/10 * * * * php -f Ping.php > /dev/null
/dev/null is the almighty black hole of a Unix system and it will swallow everything without a trace.
If I really don't want to be bothered with ANYTHING, I can also do this:
*/10 * * * * php -f Ping.php > /dev/null 2>&1
This may look weird the first time you saw it. In a nutshell, the Unix shell assigns different handlers to STDOUT and STDERR, and "2>&1" means all the errors are re-directed to standard output.
We can also create a separate cron file that has all the jobs and use the crontab command to load them up in once:
Some other notes:
Some hosting does not encourage the use of the crontab from a console. In most cases, a control panel like Cpanel provides a nice interface to set cron jobs.
Once I tried to set up cron job and it kept give me some weird error like "command not found", which made no sense since I have tested everything from the script to the PATH. It turned out the cron file I was trying to load is in DOS format and the carriage return messed it up. I ran "dos2unix" on the cron file and fixed it.