Cron versus Crontab
Cron, which name is derived from the Greek word for time chronos, is a service or program that runs on most Linux/Unix like systems, to start particular unattended jobs or tasks at either a given date/time or a predefined particular interval.
For this a configuration file, crontab, holds a list of these tasks in a rather particular format.
So Cron is the service (or program) that starts the tasks or jobs, and Crontab is the “list” or time schedule of tasks for Cron to handle.
This means that if you want to add, remove or edit scheduled jobs, you’d only have to edit the crontab file.
The short version of the story is this:
Edit crontab with
Or when you prefer to edit the file manually:
- Edit the crontab file with an editor like “VI” or “nano” (global:
/etc/config/crontab , or user:
- Make cron aware of the changes with
crontab /etc/crontab or
On to the real detailed info …
Proceed at your own risk!
Even though I should not have to say this, but please think before you do … proceed at you own risk!
– It is recommended to work with the crontab file on user level (typically ~/,crontab) if you can (not always an option on a NAS).
– Always make a backup of your crontab file before you start dabbling it … better safe than sorry.
Location of Crontab
The location of the crontab file, on most Linux systems, including Linux based NAS systems, is pretty straight forward. But, when you keep reading you might find that the location might not be all that important …
Linux based systems
First of all, in a multiuser environment we can say that there are two levels: Global (for the entire system) and User (for each individual) level.
Global is of course to be used for systemwide tasks, like for example collecting trash, etc.
User level cron tasks are of course just for the individual user …
Network Attached Storage devices
Keep in mind that the better NAS devices also run a Linux variation, like QNAP or Synology NAS devices.
For these devices, cron works as well although you’d probably stick to the global crontab and you’ll need to use an SSH connection to get to the command line (typically via “ssh admin@<NAS IP Address>” or through an application like PuTTY).
On a QNAP you will find the crontab at
QNAP recommend this approach to add items:
echo "1 4 * * * /share/custom/scripts/custom1.sh" >> /etc/config/crontab
echo "40 5 * * * /share/custom/scripts/custom2.sh" >> /etc/config/crontab
crontab /etc/config/crontab && /etc/init.d/crond.sh restart
MacOS X should be considered a Linux flavor as well – or more correct: a FreeBSD flavor – and uses Cron as well.
For the Mac however, a manually created global crontab,
/etc/crontab, might be removed automatically if you don’t use
sudo touch /etc/crontab before restarting.
The user specific file (
~/.crontab) is said to work as usual.
Microsoft Windows does not use Cron, but does have a similar function onboard, the Windows Task Scheduler, which obviously isn’t compatible with cron or the use of crontab. However, if you’d like to use Cron under Windows, then look at free applications like CronW (might not support modern Windows versions) or PyCron,.
Differences in Cron Implementations
There is a wide variety of Cron implementations out there, and they don’t all behave exactly the same.
Some options are not commonly supported, like adding a year parameter or the use of a question mark.
In this article we try to avoid these “special” options so if you’re looking for these special options, consult the manual of the developer or use in the shell the man statement:
Crontab is a simple text file, which utilizes a sometimes confusing format to set date, time or interval, and can be edited with any plain text editor. My favorite used to be “VI“, until I discovered “nano“, both are available on most Linux like systems.
We can use a direct call to open the crontab file:
Or we can use Crontab (recommended) to open the file by itself:
The latter uses the default editor, and saves you the trouble of finding the crontab file.
“crontab -e” … Choose your own editor …
The statement “crontab -e” often defaults to the use of “VI“, but why use “VI” if we can define our editor of preference by setting the EDITOR environment variable? I for one prefer the use of “nano” …
The way to do this depends on the shell you’re using …
Note that Bash is the most commonly used default shell on most Linux, FreeBSD and other Linux like systems like MacOS X.
setenv EDITOR nano
For some Cron versions, with BusyBox for example, the environment variable VISUAL should be set instead. See line 319 in the BusyBox code.
Keep in mind that Busybox is used in an aweful lot of devices: NAS boxes (like QNAP), Routers, Modem, Mobile devices, Satellite and cable boxes, etc.
Tip : The easiest way to find out which one works for you: simply execute the 3 statements one at a time followed by
crontab -e to see which editor opens.
Each line in the crontab represents such a job and the format of each line is build out of 6 or 7 parameters separated by spaces.
The optional value, the username, is placed between de “DayOfWeek” and “Command” parameters ensuring that the job is run as that user. But in all honesty – I have never used it (directly).
The first 5 are parameters related to the timing, followed by the optional username and the required file or statement(s) you’d like to execute, which can be a script or a program.
Tip : There are several so called “cron generators” online available. Although I have found that none of them is really good or complete, it might get you started building lines for your crontab. I found that the cron generator at EasyCron is probably one of the better ones.
Minutes Hours DayOfMonth Month DayOfWeek Username Command
||0 – 59
||0 – 23
||Use military (24 hour) time!
||0 – 31
||0 – 12
||JAN – DEC
||0 – 6
||SUN – SAT
||0 = Sunday, 6 = Saturday
||Optional – Name of the user to execute the job as
||Valid command line statement
As an illustration, the following example runs a backup script (
/bin/backup.sh ) every night at 0:30 AM:
30 0 * * * /bin/backup.sh
In the example, you already see that certain special characters can be used to tweak the individual parameters.
The following special characters can be used for all time related parameters (so not for the command line):
||Step size (every)
• Asterisk – Every (all)
When we use the “*” for example for the Month parameter, then the rule goes for “every month“.
Tip : A common mistake is to use “*” for example for Minutes, which will cause high system loads as the command is executed every minute.
• Slash – Step Size (every)
The “/” is useful for repeating patterns.
For example a value of */2 in the DayOfMonth parameter would mean that the command will run “every two days“.
Likewise, */5 in the Minutes parameter would mean that the command will run “every 5 Minutes“.
• Comma – And (List)
With the comma, we can provide a list …
For example 1,10,20 for DayOfMonth means that the command will be executed the “1st, 10th, and the 20th day of the month“.
• Minus or Hyphen – To (Range)
Of course making a list with individual items in it can be written shorter and this is where the minus or hyphen comes in.
When we enter 1-5 for DayOfWeek, the command will be executed on the “Days 1 to 5 of each week“, or in other words “Monday (1), Tuesday (2), Wednesday (3), Thursday (4) and Friday (5) of each week“.
Additional Special Characters (not for all parameters)
Besides the most common characters that we just discussed, some less used but practical characters. These however cannot be used in all parameters, unlike the previously presented special characters.
For DayOfMonth or DayOfWeek we can also use “L” which can be read as “Last“.
3L for the DayOfWeek means the “Last Wednesday of the Month“,
L for the DayOfMonth means the “last day of the month“.
• Nearest Week Day
DayOfMonth also allows “W” to indicate “Nearest week day“.
10W for DayOfMonth means “the weekday (business day) nearest to the 10th of the month“.
So if the 10th is a Sunday, the job will run on Monday the 11th, if the 10th is a Saturday, the job will run on Friday the 9th.
• Xth Weekday of the Month
DayOfWeek has the option to use a “#” (hash or pound) to indicate the “Xth weekday of the month“.
The # following a weekday number, must be followed by a number (0 – 5) indicating the occurance count of that weekday in a given month.
6#3 stands for the “the 3rd Friday (6 = Friday) of the month“.
• Newline or Carriage return
In the Command parameter, you can use a “%” as a “new line” (or carriage return) character (unless escaped with a slash).
A common mistake is that statements that already include a percent symbol should have it escaped as such: “\%“.
The percent symbol, if not escaped, will be seen as a carriage return!
As you might have seen in the previous examples, the numbers for the parameters and the special characters can be combined, and this is where we can achieve some really detailed timing or intervals.
We will illustrate the capabilities with a few examples:
||What it does
|0 */2 * * * /bin/backup.sh
||Run backup.sh every day, on every even hour
|0 1-23/2 * * * /bin/backup.sh
||Run backup.sh every day on every odd hour
We only use the hours 1 to 23 which makes it count only the odd hours.
|*/15 * * * * /bin/backup.sh
||Run backup.sh every 15 minutes
|0 */6 * * * /bin/backup.sh
||Run backup.sh every 6 hours
|0 0 * * 2 /bin/backup.sh
||Run backup.sh at midnight on every Tuesday (2)
|0 12 1-15,17,20-25 * * /bin/backup.sh
||Run backup.sh at noon on the 1st to 15th, the 17th, and the 20th till the 25th of each month
|* 12 10-16/2 * * /bin/backup.sh
||Run backup.sh at noon on the 10th, 12th, 14th and 16th day of the month
|* 12 10,12,14,16 * * /bin/backup.sh
||Is the same as the previous one: Run backup.sh at noon on the 10th, 12th, 14th and 16th day of the month
|0 0 * * 0,6 /bin/backup.sh
||Run backup.sh at midnight on every weekend day (Sunday = 0 and Saturday = 6)
|30 12 * * 1-5 /bin/backup.sh
||Run backup.sh every business day at 12:30 PM (Monday =1, Friday = 5)
|0 5 1 */3 * /bin/backup.sh
||Run backup.sh every first day of the quarter (3 months) at 5 AM
|0 0 22 10 * /bin/happybirthday.sh
||Run happybirthday.sh every year on Oct 22nd at midnight.
Predefined @ Statements
Cron also knows a few statements or abbreviations that might become in handy:
||Execute at reboot of your computer or when Cron restarts
||Execute job every day at midnight
||Same as @daily – Execute a job everyday at midnight
||Execute job every Sunday at midnight
||Execute job at the 1st day of the month at midnight
||Execute job every January 1st at midnight of each year (Januari 1st)
||Same as @yearly
An example that runs
/bin/backup.sh every day at midnight:
In Cron you can define some environment variables, but to minimize confusion I always stick to the default values.
These variables should be set in the first lines in crontab, so that Cron is aware of them when executing jobs.
||Set the shell Cron should use
||Set the search path for Cron commands
||Set the home directory for Cron
||Set who receives the output as an emal
Please eMail me the results
As you might have seen just now: Cron has the ability, in most implementations anyway, to send an email with the results.
To enable this add a first line like such:
Alternatively, depending on the Cron implementation, and email address can be used:
Output – Dump it in a file or Mute it …
Output of an individual command/statement/script can also be redirected to a file.
In the example below, the script
/bin/test.sh is executed every day at midnight and the output is dumped in the file
0 0 * * * /bin/test.sh > /etc/test.txt
Output can also be muted, meaning the output is thrown away.
0 0 * * * /bin/test.sh >/dev/null 2>&1