想要让cron执行你指定的任务，首先就要编辑crontab文件。crontab是一个文本文件，用来存放你要运行的命令。你可以以下命令

crontab -e

来打开你的用户所属的crontab文件。第一次用这个命令，会让你选择文本编辑器，我选的是vim。选定的编辑器也可以使用

select-editor

命令来更改。这点命令行中已经有足够的提示，就不多说了。

打开后的crontab文件类似这种样子：

第二行是我为了测试写的一个定期任务，它的意思是，每隔两分钟就执行 date >> ~/time.log 命令（记录当前时间到time.log文件）。你可以把它加入你的crontab中，然后保存退出。

保存了crontab之后，我们还需要重启cron来应用这个计划任务。使用以下命令：

下面稍微解释下crontab中每行的含义。crontab中的每一行代表一个定期执行的任务，分为6个部分。前5个部分表示何时执行命令，最后一 个部分表示执行的命令。每个部分以空格分隔，除了最后一个部分（命令）可以在内部使用空格之外，其他部分都不能使用空格。前5个部分分别代表：分钟，小 时，天，月，星期，每个部分的取值范围如下：

分钟          0 – 59

小时          0 – 23

天              1 – 31

月              1 – 12

星期          0 – 6       0表示星期天

除了这些固定值外，还可以配合星号（*），逗号（,），和斜线（/）来表示一些其他的含义：

星号          表示任意值，比如在小时部分填写 * 代表任意小时（每小时）

逗号          可以允许在一个部分中填写多个值，比如在分钟部分填写 1,3 表示一分钟或三分钟

斜线          一般配合 * 使用，代表每隔多长时间，比如在小时部分填写 */2 代表每隔两分钟。所以 */1 和 * 没有区别

*/2 可以看成是能被2整除的任意值。

以下是一些例子（省略了命令部分）：

 

以上就是在cron中加入计划任务的基本知识。因为cron中的任务基本就是执行命令行，所以当然也会有权限问题。以上例子中的任务就是以你当前登录用户的权限执行的，如果你需要以root用户执行某个任务，可以在crontab前加上sudo。

顺带一提，crontab文件对每个用户都是不同的，所以刚才设置的定期看时间的任务，在这里是看不到的。因为我们没有为root用户增加这样的计划任务。

原文

https://help.ubuntu.com/community/CronHowto

Introduction

Cron is a system daemon used to execute desired tasks (in the background) at designated times.

A crontab is a simple text file with a list of commands meant to be run at specified times. It is edited with a command-line utility. These commands (and their run times) are then controlled by the cron daemon, which executes them in the system background. Each user has a crontab file which specifies the actions and times at which they should be executed, these jobs will run regardless of whether the user is actually logged into the system. There is also a root crontab for tasks requiring administrative privileges. This system crontab allows scheduling of systemwide tasks (such as log rotations and system database updates).

More information can be found:

 man crontab

or from the OpenGroup specifications.

On Gnome-based Ubuntu systems Gnome Scheduled tasks tool (from the gnome-schedule package) in Applications –> System Tools provides a graphical interface with prompting for using Cron. The project website is at http://gnome-schedule.sourceforge.net/; the software is installable from the Software Center or by typing

sudo apt-get install gnome-schedule

in a terminal.

Using Cron

To use cron for tasks meant to run only for your user profile, add entries to your own user’s crontab file. Start the crontab editor from a terminal window:

crontab -e

Edit the crontab using the format described in the next sections. Save your changes. (Exiting without saving will leave your crontab unchanged.)

Note that a great source of information about the format can be found at:

man 5 crontab

Commands that normally run with administrative privileges (i.e. they are generally run using sudo) should be added to the root user’s crontab (instead of the user’s crontab):

 sudo crontab -e

Crontab Sections

Each of the sections is separated by a space, with the final section having one or more spaces in it. No spaces are allowed within Sections 1-5, only between them. Sections 1-5 are used to indicate when and how often you want the task to be executed. This is how a cron job is laid out:

minute (0-59), hour (0-23, 0 = midnight), day (1-31), month (1-12), weekday (0-6, 0 = Sunday), command

01 04 1 1 1 /usr/bin/somedirectory/somecommand

The above example will run /usr/bin/somedirectory/somecommand at 4:01am on January 1st plus every Monday in January. An asterisk (*) can be used so that every instance (every hour, every weekday, every month, etc.) of a time period is used. Code:

01 04 * * * /usr/bin/somedirectory/somecommand

The above example will run /usr/bin/somedirectory/somecommand at 4:01am on every day of every month.

Comma-separated values can be used to run more than one instance of a particular command within a time period. Dash-separated values can be used to run a command continuously. Code:

01,31 04,05 1-15 1,6 * /usr/bin/somedirectory/somecommand

The above example will run /usr/bin/somedirectory/somecommand at 01 and 31 past the hours of 4:00am and 5:00am on the 1st through the 15th of every January and June.

The “/usr/bin/somedirectory/somecommand” text in the above examples indicates the task which will be run at the specified times. It is recommended that you use the full path to the desired commands as shown in the above examples. Enter which somecommand in the terminal to find the full path to somecommand. The crontab will begin running as soon as it is properly edited and saved.

You may want to run a script some number of times per time unit. For example if you want to run it every 10 minutes use the following crontab entry (runs on minutes divisible by 10: 0, 10, 20, 30, etc.)

*/10 * * * * /usr/bin/somedirectory/somecommand

which is also equivalent to the more cumbersome

0,10,20,30,40,50 * * * * /usr/bin/somedirectory/somecommand

Crontab Options

• The -l option causes the current crontab to be displayed on standard output.
• The -r option causes the current crontab to be removed.
• The -e option is used to edit the current crontab using the editor specified by the EDITOR environment variable.

After you exit from the editor, the modified crontab will be checked for accuracy and, if there are no errors, installed automatically. The file is stored in /var/spool/cron/crontabs but should only be edited via the crontab command.

Enable User Level Cron

If the /etc/cron.allow file exists, then users must be listed in it in order to be allowed to run the crontab command. If the /etc/cron.allow file does not exist but the /etc/cron.deny file does, then users must not be listed in the /etc/cron.deny file in order to run crontab.

In the case where neither file exists, the default on current Ubuntu (and Debian, but not some other Linux and UNIX systems) is to allow all users to run jobs with crontab.

No cron.allow or cron.deny files exist in a standard Ubuntu install, so all users should have cron available by default, until one of those files is created. If a blank cron.deny file has been created, that will change to the standard behavior users of other operating systems might expect: cron only available to root or users in cron.allow.

Note, userids on your system which do not appear in /etc/shadow will NOT have operational crontabs, if you desire to enter a user in /etc/passwd, but NOT /etc/shadow that user’s crontab will never run. Place an entry in /etc/shadow for the user with a * for the password crypt,ie:

joeuser:*:15169::::::

Further Considerations

Crontab commands are generally stored in the crontab file belonging to your user account (and executed with your user’s level of permissions). If you want to regularly run a command requiring administrative permissions, edit the root crontab file:

sudo crontab -e

Depending on the commands being run, you may need to expand the root users PATH variable by putting the following line at the top of their crontab file:

PATH=/usr/sbin:/usr/bin:/sbin:/bin

It is sensible to test that your cron jobs work as intended. One method for doing this is to set up the job to run a couple of minutes in the future and then check the results before finalising the timing. You may also find it useful to put the commands into script files that log their success or failure, for example:

echo "Nightly Backup Successful: $(date)" >> /tmp/mybackup.log

For more information, see the man pages for cron and crontab (man is detailed on the BasicCommands page). If your machine is regularly switched off, you may also be interested in at and anacron, which provide other approaches to scheduled tasks. For example, anacron offers simple system-wide directories for running commands hourly, daily, weekly, and monthly. Scripts to be executed in said times can be placed in /etc/cron.hourly/, /etc/cron.daily/, /etc/cron.weekly/, and /etc/cron.monthly/. All scripts in each directory are run as root, and a specific order to running the scripts can be specified by prefixing the scripts’ filenames with numbers (see the man page for run-parts for more details). Although the directories contain periods in their names, run-parts will not accept a file name containing a period and will fail silently when encountering them (bug #38022). Either rename the file or use a symlink (without a period) to it instead (see, for example, python + cron without login? and Problems with Hourly Cron Job).

Troubleshooting and Common Problems

Edits to a user’s crontab and jobs that are run on their behalf are all logged by default to /var/log/syslog and that’s the first place to check if things are not running as you expect.

When adding a new entry to a blank crontab, forgetting to add a newline at the end is a common source for the job not running. If the last line in the crontab does not end with a newline, no errors will be reported at edit or runtime, but that line will never run. See man crontab for more information. This has already been suggested as a bug.

If a user was not allowed to execute jobs when their crontab was last edited, just adding them to the allow list won’t do anything. The user needs to re-edit their crontab after being added to cron.allow before their jobs will run.

When creating a crontab for the root user, the user name must be specified as a parameter after the date/time parameters. Accidentally including the user name that way in a user-specific crontab will result in trying to run the user’s name as a command, rather than what was expected.

Entries in cron may not run with the same environment, in particular the PATH, as you expect them to. Try using full paths to files and programs if they’re not being located as you expect.

The “%” character is used as newline delimiter in cron commands. If you need to pass that character into a script, you need to escape it as “\%”.

If you’re having trouble running a GUI application using cron, see the GUI Applications section below.

Advanced Crontab

The Crontabs discussed above are user crontabs. Each of the above crontabs is associated with a user, even the system crontab which is associated with the root user. There are two other types of crontab.

Firstly, as mentioned above anacron uses the run-parts command and /etc/cron.hourly, /etc/cron.weekly, and /etc/cron.monthly directories. However anacron itself is invoked from the /etc/crontab file. This file could be used for other cron commands, but probably shouldn’t be. Here’s an example line from a ficticious /etc/crontab:

00 01 * * * rusty /home/rusty/rusty-list-files.sh

This would run Rusty’s command script as user rusty from his home directory. However, it is not usual to add commands to this file. While an experienced user should know about it, it is not recommended that you add anything to /etc/crontab. Apart from anything else, this could cause problem if the /etc/crontab file is affected by updates! Rusty could lose his command.

The second type of crontab is to be found in /etc/cron.d. Within the directory are small named crontabs. The directory is often used by packages, and the small crontabs allows a user to be associated with the commands in them.

Instead of adding a line to /etc/crontab which Rusty knows is not a good idea, Rusty might well add a file to /etc/cron.d with the name rusty, containing his cron line above. This would not be affected by updates but is a well known location.

When would you use these alternate crontab locations? Well, on a single user machine or a shared machine such as a school or college server, a user crontab would be the way to go. But in a large IT department, where several people might look after a server, then /etc/cron.d is probably the best place to install crontabs – it’s a central point and saves searching for them!

You may not need to look at /etc/crontab or /etc/cron.d, let alone edit them by hand. But an experienced user should perhaps know about them and that the packages that he/she installs may use these locations for their crontabs.

Special strings

Cron also offers some special strings:

• string	meaning
  @reboot	Run once, at startup.
  @yearly	Run once a year, “0 0 1 1 *”.
  @annually	(same as @yearly)
  @monthly	Run once a month, “0 0 1 * *”.
  @weekly	Run once a week, “0 0 * * 0”.
  @daily	Run once a day, “0 0 * * *”.
  @midnight	(same as @daily)
  @hourly	Run once an hour, “0 * * * *”.

Usage: “@reboot /path/to/execuable1” will execute /path/to/executable1 when the system starts. See “man 5 crontab” for more info.

GUI Applications

It is possible to run gui applications via cronjobs. This can be done by telling cron which display to use.

00 06 * * * env DISPLAY=:0 gui_appname

The env DISPLAY=:0 portion will tell cron to use the current display (desktop) for the program “gui_appname”.

And if you have multiple monitors, don’t forget to specify on which one the program is to be run. For example, to run it on the first screen (default screen) use :

00 06 * * * env DISPLAY=:0.0 gui_appname

The env DISPLAY=:0.0 portion will tell cron to use the first screen of the current display for the program “gui_appname”.

Note: GUI users may prefer to use gnome-schedule (aka “Scheduled tasks”) to configure GUI cron jobs. In gnome-schedule, when editing a GUI task, you have to select “X application” in a dropdown next to the command field.

Note: In Karmic(9.10), you have to enable X ACL for localhost to connect to for GUI applications to work.

 ~$ xhost +local:
non-network local connections being added to access control list
 ~$ xhost
access control enabled, only authorized clients can connect
LOCAL:
...

Tips

crontab -e uses the EDITOR environment variable. to change the editor to your own choice just set that. You may want to set EDITOR in you .bashrc because many commands use this variable. Let’s set the EDITOR to nano a very easy editor to use:

export EDITOR=nano

There are also files you can edit for system-wide cron jobs. The most common file is located at /etc/crontab, and this file follows a slightly different syntax than a normal crontab file. Since it is the base crontab that applies system-wide, you need to specify what user to run the job as; thus, the syntax is now:

minute(s) hour(s) day(s)_of_month month(s) day(s)_of_week user command

It is recommended, however, that you try to avoid using /etc/crontab unless you need the flexibility offered by it, or if you’d like to create your own simplified anacron-like system using run-parts for example. For all cron jobs that you want to have run under your own user account, you should stick with using crontab -e to edit your local cron jobs rather than editting the system-wide /etc/crontab.

Crontab Example

Below is an example of how to setup a crontab to run updatedb, which updates the slocate database: Open a term, type “crontab -e” (without the double quotes) and press enter. Type the following line, substituting the full path of the application you wish to run for the one shown below, into the editor:

45 04 * * * /usr/bin/updatedb

Save your changes and exit the editor.

Crontab will let you know if you made any mistakes. The crontab will be installed and begin running if there are no errors. That’s it. You now have a cronjob setup to run updatedb, which updates the slocate database, every morning at 4:45.

Note: The double-ampersand (&&) can also be used in the “command” section to run multiple commands consecutively, but only if the previous command exits successfully. A string of commands joined by the double-ampersand will only get to the last command if all the previous commands are run successfully. If exit error-checking is not of a concern, string commands together, separated with a semi-colon (;)

45 04 * * * /usr/sbin/chkrootkit && /usr/bin/updatedb

The above example will run chkrootkit followed by updatedb at 4:45am daily – providing you have all listed apps installed. If chkrootkit fails, updatedb will NOT be run.

How Anacron is Arranged

On Ubuntu 9.10 (and presumably, on later versions), anacron seems to be set up as follows:

There is a Upstart task, located in /etc/init/anacron.conf, which runs all the jobs in /etc/anacrontab. It is set to run on startup.

There is a cron.d file (/etc/cron.d/anacron) which causes the Upstart task to be started every day at 7:30 AM.

There is a file /etc/apm/event.d/anacron, which causes the Upstart task to be started when a laptop is plugged in to A/C power, or woken up.

In the system crontab (/etc/crontab), if anacron is not execuatable, run-parts is used to run the files in cron.daily, cron.weekly, and cron.monthly at 6:25 AM, 6:47 AM and 6:52 AM, respectively.

In /etc/anacrontab, run-parts is used to run cron.daily 5 minutes after anacron is started, and cron.weekly after 10 minutes (once a week), and cron.monthly after 15 (once a month).

Within the cron.daily, weekly, and monthly directories ( /etc/cron.daily, etc.) there is a 0anacron file that sets the timestamps for anacron, so it will know they have been run, even if it didn’t run them.

So it appears anacron is run on every startup, wake up, plug-in, and at 7:30 AM every day. Looking at the respective Changelogs and package databases, it looks like this setup is directly from Debian, and hasn’t been changed since at least 2009.