document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2025-01-01 21:50:13 +08:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #6264 from qhwdw/master

Browse Source 
Translated by qhwdw
This commit is contained in:
Xingyu.Wang 2017-11-14 08:28:42 -06:00 committed by GitHub
commit 942175df61
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 284 additions and 284 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

284
sources/tech/20171101 How to use cron in Linux.md
View File

@ -1,284 +0,0 @@
Translating by qhwdw How to use cron in Linux
============================================================
### No time for commands? Scheduling tasks with cron means programs can run but you don't have to stay up late.
![How to use cron in Linux](https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/linux-penguins.png?itok=yKOpaJM_ "How to use cron in Linux")
Image by : [Internet Archive Book Images][11]. Modified by Opensource.com. [CC BY-SA 4.0][12]
One of the challenges (among the many advantages) of being a sysadmin is running tasks when you'd rather be sleeping. For example, some tasks (including regularly recurring tasks) need to run overnight or on weekends, when no one is expected to be using computer resources. I have no time to spare in the evenings to run commands and scripts that have to operate during off-hours. And I don't want to have to get up at oh-dark-hundred to start a backup or major update.
Instead, I use two service utilities that allow me to run commands, programs, and tasks at predetermined times. The [**cron**][13] and **at** services enable sysadmins to schedule tasks to run at a specific time in the future. The at service specifies a one-time task that runs at a certain time. The cron service can schedule tasks on a repetitive basis, such as daily, weekly, or monthly.
In this article, I'll introduce the cron service and how to use it.
### Common (and uncommon) cron uses
I use the **cron** service to schedule obvious things, such as regular backups that occur daily at 2 a.m. I also use it for less obvious things.
* The system times (i.e., the operating system time) on my many computers are set using the Network Time Protocol (NTP). While NTP sets the system time, it does not set the hardware time, which can drift. I use cron to set the hardware time based on the system time.
* I also have a Bash program I run early every morning that creates a new "message of the day" (MOTD) on each computer. It contains information, such as disk usage, that should be current in order to be useful.
* Many system processes and services, like [Logwatch][7], [logrotate][8], and [Rootkit Hunter][9], use the cron service to schedule tasks and run programs every day.
The **crond** daemon is the background service that enables cron functionality.
The cron service checks for files in the **/var/spool/cron** and **/etc/cron.d** directories and the **/etc/anacrontab** file. The contents of these files define cron jobs that are to be run at various intervals. The individual user cron files are located in **/var/spool/cron**, and system services and applications generally add cron job files in the **/etc/cron.d** directory. The **/etc/anacrontab** is a special case that will be covered later in this article.
### Using crontab
The cron utility runs based on commands specified in a cron table (**crontab**). Each user, including root, can have a cron file. These files don't exist by default, but can be created in the **/var/spool/cron** directory using the **crontab -e** command that's also used to edit a cron file (see the script below). I strongly recommend that you  _not_  use a standard editor (such as Vi, Vim, Emacs, Nano, or any of the many other editors that are available). Using the **crontab** command not only allows you to edit the command, it also restarts the **crond** daemon when you save and exit the editor. The **crontab** command uses Vi as its underlying editor, because Vi is always present (on even the most basic of installations).
New cron files are empty, so commands must be added from scratch. I added the job definition example below to my own cron files, just as a quick reference, so I know what the various parts of a command mean. Feel free to copy it for your own use.
```
# crontab -e
SHELL=/bin/bash
MAILTO=root@example.com
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
# For details see man 4 crontabs
# Example of job definition:
# .---------------- minute (0 - 59)
# |  .------------- hour (0 - 23)
# |  |  .---------- day of month (1 - 31)
# |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
# |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# |  |  |  |  |
# *  *  *  *  * user-name  command to be executed
# backup using the rsbu program to the internal 4TB HDD and then 4TB external
01 01 * * * /usr/local/bin/rsbu -vbd1 ; /usr/local/bin/rsbu -vbd2
# Set the hardware clock to keep it in sync with the more accurate system clock
03 05 * * * /sbin/hwclock --systohc
# Perform monthly updates on the first of the month
# 25 04 1 * * /usr/bin/dnf -y update
```
The **crontab **command is used to view or edit the cron files.
The first three lines in the code above set up a default environment. The environment must be set to whatever is necessary for a given user because cron does not provide an environment of any kind. The **SHELL** variable specifies the shell to use when commands are executed. This example specifies the Bash shell. The **MAILTO** variable sets the email address where cron job results will be sent. These emails can provide the status of the cron job (backups, updates, etc.) and consist of the output you would see if you ran the program manually from the command line. The third line sets up the **PATH** for the environment. Even though the path is set here, I always prepend the fully qualified path to each executable.
There are several comment lines in the example above that detail the syntax required to define a cron job. I'll break those commands down, then add a few more to show you some more advanced capabilities of crontab files.
```
01 01 * * * /usr/local/bin/rsbu -vbd1 ; /usr/local/bin/rsbu -vbd2
```
This line in my **/etc/crontab** runs a script that performs backups for my systems.
This line runs my self-written Bash shell script, **rsbu**, that backs up all my systems. This job kicks off at 1:01 a.m. (01 01) every day. The asterisks (*) in positions three, four, and five of the time specification are like file globs, or wildcards, for other time divisions; they specify "every day of the month," "every month," and "every day of the week." This line runs my backups twice; one backs up to an internal dedicated backup hard drive, and the other backs up to an external USB drive that I can take to the safe deposit box.
The following line sets the hardware clock on the computer using the system clock as the source of an accurate time. This line is set to run at 5:03 a.m. (03 05) every day.
```
03 05 * * * /sbin/hwclock --systohc
```
This line sets the hardware clock using the system time as the source.
I was using the third and final cron job (commented out) to perform a **dnf** or **yum** update at 04:25 a.m. on the first day of each month, but I commented it out so it no longer runs.
```
# 25 04 1 * * /usr/bin/dnf -y update
```
This line used to perform a monthly update, but I've commented it out.
### Other scheduling tricks
Now let's do some things that are a little more interesting than these basics. Suppose you want to run a particular job every Thursday at 3 p.m.:
```
00 15 * * Thu /usr/local/bin/mycronjob.sh
```
This line runs **mycronjob.sh** every Thursday at 3 p.m.
Or, maybe you need to run quarterly reports after the end of each quarter. The cron service has no option for "The last day of the month," so instead you can use the first day of the following month, as shown below. (This assumes that the data needed for the reports will be ready when the job is set to run.)
```
02 03 1 1,4,7,10 * /usr/local/bin/reports.sh
```
This cron job runs quarterly reports on the first day of the month after a quarter ends.
The following shows a job that runs one minute past every hour between 9:01 a.m. and 5:01 p.m.
```
01 09-17 * * * /usr/local/bin/hourlyreminder.sh
```
Sometimes you want to run jobs at regular times during normal business hours.
I have encountered situations where I need to run a job every two, three, or four hours. That can be accomplished by dividing the hours by the desired interval, such as ***/3** for every three hours, or **6-18/3** to run every three hours between 6 a.m. and 6 p.m. Other intervals can be divided similarly; for example, the expression ***/15** in the minutes position means "run the job every 15 minutes."
```
*/5 08-18/2 * * * /usr/local/bin/mycronjob.sh
```
This cron job runs every five minutes during every hour between 8 a.m. and 5:58 p.m.
One thing to note: The division expressions must result in a remainder of zero for the job to run. That's why, in this example, the job is set to run every five minutes (08:05, 08:10, 08:15, etc.) during even-numbered hours from 8 a.m. to 6 p.m., but not during any odd-numbered hours. For example, the job will not run at all from 9 p.m. to 9:59 a.m.
I am sure you can come up with many other possibilities based on these examples.
### Limiting cron access
More Linux resources
* [What is Linux?][1]
* [What are Linux containers?][2]
* [Download Now: Linux commands cheat sheet][3]
* [Advanced Linux commands cheat sheet][4]
* [Our latest Linux articles][5]
Regular users with cron access could make mistakes that, for example, might cause system resources (such as memory and CPU time) to be swamped. To prevent possible misuse, the sysadmin can limit user access by creating a **/etc/cron.allow** file that contains a list of all users with permission to create cron jobs. The root user cannot be prevented from using cron.
By preventing non-root users from creating their own cron jobs, it may be necessary for root to add their cron jobs to the root crontab. "But wait!" you say. "Doesn't that run those jobs as root?" Not necessarily. In the first example in this article, the username field shown in the comments can be used to specify the user ID a job is to have when it runs. This prevents the specified non-root user's jobs from running as root. The following example shows a job definition that runs a job as the user "student":
```
04 07 * * * student /usr/local/bin/mycronjob.sh
```
If no user is specified, the job is run as the user that owns the crontab file, root in this case.
### cron.d
The directory **/etc/cron.d** is where some applications, such as [SpamAssassin][14] and [sysstat][15], install cron files. Because there is no spamassassin or sysstat user, these programs need a place to locate cron files, so they are placed in **/etc/cron.d**.
The **/etc/cron.d/sysstat** file below contains cron jobs that relate to system activity reporting (SAR). These cron files have the same format as a user cron file.
```
# Run system activity accounting tool every 10 minutes
*/10 * * * * root /usr/lib64/sa/sa1 1 1
# Generate a daily summary of process accounting at 23:53
53 23 * * * root /usr/lib64/sa/sa2 -A
```
The sysstat package installs the **/etc/cron.d/sysstat** cron file to run programs for SAR.
The sysstat cron file has two lines that perform tasks. The first line runs the **sa1** program every 10 minutes to collect data stored in special binary files in the **/var/log/sa** directory. Then, every night at 23:53, the **sa2** program runs to create a daily summary.
### Scheduling tips
Some of the times I set in the crontab files seem rather random—and to some extent they are. Trying to schedule cron jobs can be challenging, especially as the number of jobs increases. I usually have only a few tasks to schedule on each of my computers, which is simpler than in some of the production and lab environments where I have worked.
One system I administered had around a dozen cron jobs that ran every night and an additional three or four that ran on weekends or the first of the month. That was a challenge, because if too many jobs ran at the same time—especially the backups and compiles—the system would run out of RAM and nearly fill the swap file, which resulted in system thrashing while performance tanked, so nothing got done. We added more memory and improved how we scheduled tasks. We also removed a task that was very poorly written and used large amounts of memory.
The crond service assumes that the host computer runs all the time. That means that if the computer is turned off during a period when cron jobs were scheduled to run, they will not run until the next time they are scheduled. This might cause problems if they are critical cron jobs. Fortunately, there is another option for running jobs at regular intervals: **anacron**.
### anacron
The [anacron][16] program performs the same function as crond, but it adds the ability to run jobs that were skipped, such as if the computer was off or otherwise unable to run the job for one or more cycles. This is very useful for laptops and other computers that are turned off or put into sleep mode.
As soon as the computer is turned on and booted, anacron checks to see whether configured jobs missed their last scheduled run. If they have, those jobs run immediately, but only once (no matter how many cycles have been missed). For example, if a weekly job was not run for three weeks because the system was shut down while you were on vacation, it would be run soon after you turn the computer on, but only once, not three times.
The anacron program provides some easy options for running regularly scheduled tasks. Just install your scripts in the **/etc/cron.[hourly|daily|weekly|monthly]** directories, depending how frequently they need to be run.
How does this work? The sequence is simpler than it first appears.
1. The crond service runs the cron job specified in **/etc/cron.d/0hourly**.
```
# Run the hourly jobs
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
01 * * * * root run-parts /etc/cron.hourly
```
The contents of **/etc/cron.d/0hourly** cause the shell scripts located in **/etc/cron.hourly** to run.
1. The cron job specified in **/etc/cron.d/0hourly** runs the **run-parts** program once per hour.
2. The **run-parts** program runs all the scripts located in the **/etc/cron.hourly** directory.
3. The **/etc/cron.hourly** directory contains the **0anacron** script, which runs the anacron program using the **/etdc/anacrontab** configuration file shown here.
```
# /etc/anacrontab: configuration file for anacron
# See anacron(8) and anacrontab(5) for details.
SHELL=/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
# the maximal random delay added to the base delay of the jobs
RANDOM_DELAY=45
# the jobs will be started during the following hours only
START_HOURS_RANGE=3-22
#period in days   delay in minutes   job-identifier   command
1       5       cron.daily              nice run-parts /etc/cron.daily
7       25      cron.weekly             nice run-parts /etc/cron.weekly
@monthly 45     cron.monthly            nice run-parts /etc/cron.monthly
```
The contents of **/etc/anacrontab** file runs the executable files in the **cron.[daily|weekly|monthly]** directories at the appropriate times.
1. The anacron program runs the programs located in **/etc/cron.daily** once per day; it runs the jobs located in **/etc/cron.weekly** once per week, and the jobs in **cron.monthly** once per month. Note the specified delay times in each line that help prevent these jobs from overlapping themselves and other cron jobs.
Instead of placing complete Bash programs in the **cron.X** directories, I install them in the **/usr/local/bin** directory, which allows me to run them easily from the command line. Then I add a symlink in the appropriate cron directory, such as **/etc/cron.daily**.
The anacron program is not designed to run programs at specific times. Rather, it is intended to run programs at intervals that begin at the specified times, such as 3 a.m. (see the **START_HOURS_RANGE** line in the script just above) of each day, on Sunday (to begin the week), and on the first day of the month. If any one or more cycles are missed, anacron will run the missed jobs once, as soon as possible.
### More on setting limits
I use most of these methods for scheduling tasks to run on my computers. All those tasks are ones that need to run with root privileges. It's rare in my experience that regular users really need a cron job. One case was a developer user who needed a cron job to kick off a daily compile in a development lab.
It is important to restrict access to cron functions by non-root users. However, there are circumstances when a user needs to set a task to run at pre-specified times, and cron can allow them to do that. Many users do not understand how to properly configure these tasks using cron and they make mistakes. Those mistakes may be harmless, but, more often than not, they can cause problems. By setting functional policies that cause users to interact with the sysadmin, individual cron jobs are much less likely to interfere with other users and other system functions.
It is possible to set limits on the total resources that can be allocated to individual users or groups, but that is an article for another time.
For more information, the man pages for [cron][17], [crontab][18], [anacron][19], [anacrontab][20], and [run-parts][21] all have excellent information and descriptions of how the cron system works.
--------------------------------------------------------------------------------
作者简介：
David Both - David Both is a Linux and Open Source advocate who resides in Raleigh, North Carolina. He has been in the IT industry for over forty years and taught OS/2 for IBM where he worked for over 20 years. While at IBM, he wrote the first training course for the original IBM PC in 1981. He has taught RHCE classes for Red Hat and has worked at MCI Worldcom, Cisco, and the State of North Carolina. He has been working with Linux and Open Source Software for almost 20 years.
---------------------------
via: https://opensource.com/article/17/11/how-use-cron-linux
作者：[David Both ][a]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]:https://opensource.com/users/dboth
[1]:https://opensource.com/resources/what-is-linux?intcmp=70160000000h1jYAAQ&utm_source=intcallout&utm_campaign=linuxcontent
[2]:https://opensource.com/resources/what-are-linux-containers?intcmp=70160000000h1jYAAQ&utm_source=intcallout&utm_campaign=linuxcontent
[3]:https://developers.redhat.com/promotions/linux-cheatsheet/?intcmp=70160000000h1jYAAQ&utm_source=intcallout&utm_campaign=linuxcontent
[4]:https://developers.redhat.com/cheat-sheet/advanced-linux-commands-cheatsheet?intcmp=70160000000h1jYAAQ&utm_source=intcallout&utm_campaign=linuxcontent
[5]:https://opensource.com/tags/linux?intcmp=70160000000h1jYAAQ&utm_source=intcallout&utm_campaign=linuxcontent
[6]:https://opensource.com/article/17/11/how-use-cron-linux?rate=9R7lrdQXsne44wxIh0Wu91ytYaxxi86zT1-uHo1a1IU
[7]:https://sourceforge.net/projects/logwatch/files/
[8]:https://github.com/logrotate/logrotate
[9]:http://rkhunter.sourceforge.net/
[10]:https://opensource.com/user/14106/feed
[11]:https://www.flickr.com/photos/internetarchivebookimages/20570945848/in/photolist-xkMtw9-xA5zGL-tEQLWZ-wFwzFM-aNwxgn-aFdWBj-uyFKYv-7ZCCBU-obY1yX-UAPafA-otBzDF-ovdDo6-7doxUH-obYkeH-9XbHKV-8Zk4qi-apz7Ky-apz8Qu-8ZoaWG-orziEy-aNwxC6-od8NTv-apwpMr-8Zk4vn-UAP9Sb-otVa3R-apz6Cb-9EMPj6-eKfyEL-cv5mwu-otTtHk-7YjK1J-ovhxf6-otCg2K-8ZoaJf-UAPakL-8Zo8j7-8Zk74v-otp4Ls-8Zo8h7-i7xvpR-otSosT-9EMPja-8Zk6Zi-XHpSDB-hLkuF3-of24Gf-ouN1Gv-fJzkJS-icfbY9
[12]:https://creativecommons.org/licenses/by-sa/4.0/
[13]:https://en.wikipedia.org/wiki/Cron
[14]:http://spamassassin.apache.org/
[15]:https://github.com/sysstat/sysstat
[16]:https://en.wikipedia.org/wiki/Anacron
[17]:http://man7.org/linux/man-pages/man8/cron.8.html
[18]:http://man7.org/linux/man-pages/man5/crontab.5.html
[19]:http://man7.org/linux/man-pages/man8/anacron.8.html
[20]:http://man7.org/linux/man-pages/man5/anacrontab.5.html
[21]:http://manpages.ubuntu.com/manpages/zesty/man8/run-parts.8.html
[22]:https://opensource.com/users/dboth
[23]:https://opensource.com/users/dboth
[24]:https://opensource.com/article/17/11/how-use-cron-linux#comments

284
translated/tech/20171101 How to use cron in Linux.md Normal file
View File

@ -0,0 +1,284 @@
在 Linux 中怎么去使用 cron
============================================================
### 命令没有时间？使用 cron 的计划任务意味着你不用熬夜程序也可以运行。
![How to use cron in Linux](https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/linux-penguins.png?itok=yKOpaJM_ "How to use cron in Linux")
Image by : [Internet Archive Book Images][11]. Modified by Opensource.com. [CC BY-SA 4.0][12]
作为一个系统管理员的其中一个挑战（在许多好处中的）是在你该睡觉的时候去运行一些任务。例如，一些任务（包括定期循环运行的任务）需要在没有人使用计算机资源的时候去运行，如晚上或周末。在下班后，我没有时间去运行命令或脚本。而且，我不想在晚上去启动备份或主要更新。
而是，我使用两个服务实用程序，在我预定时间去运行命令、程序和任务。[**cron**][13] 和 **at** 服务允许系统管理员去安排任务在未来的某个特定时间去运行。at 服务指定一个单次的某个时间去运行任务。cron 服务可以安排任务在一个基础上重复，比如，天、周、或月。
在这篇文章中，我将介绍 cron 服务和怎么去使用它。
### 常见（和非常见）的 cron 使用
我使用 **cron** 服务去安排一些常见的事情，比如，每天凌晨 2:00 发生的定期备份，我也使用它去做一些不常见的事情。
* 许多电脑上的系统时钟（比如，操作系统时间）都设置为使用网络时间协议（NTP）。在将 NTP 设置为系统时间后，你不需要去设置硬件时间，它可能会“漂移”。我使用 cron 基于系统时间去去设置硬件时间。
* 我也有一个 Bash 程序，我在每天早晨运行它，去在每台电脑上创建一个新的 “每日信息” （MOTD）。它包含的信息有当前的磁盘使用情况。
* 许多系统进程和服务，像 [Logwatch][7]、[logrotate][8]、和 [Rootkit Hunter][9]，使用 cron 服务去安排任务和每天运行程序。
**crond** 守护进程是一个完成 cron 功能的后台服务。
cron 服务检查在**/var/spool/cron** 和 **/etc/cron.d** 目录中的文件，和**/etc/anacrontab** 文件。这些文件的内容定义了 cron 作业在不同的时间间隔中去运行。个别的用户的 cron 文件是位于 **/var/spool/cron**，而系统服务和应用生成的 cron 作业文件在 **/etc/cron.d** 目录中。**/etc/anacrontab** 是一个特殊的情况，它将在本文中稍后去介绍。
### 使用 crontab
cron 实用程序运行是基于一个 cron 表（**crontab**）中指定的命令。每个用户，包括 root，都有一个 cron 文件。这些文件缺省是不存在的。但可以在 **/var/spool/cron** 目录中使用 **crontab -e** 命令去创建，也可以使用它去编辑一个文件（看下面的脚本）。我强烈建议你，_不要_使用标准的编辑器（比如，Vi、Vim、Emacs、Nano、或者任何其它可用 的编辑器）。使用 **crontab** 命令不仅允许你去编辑命令，也可以在你保存并退出编辑器时，重启动 **crond** 守护进程。**crontab** 命令使用 Vi 作为它的底层编辑器，因为 Vi 是预装的（至少在大多数的基本安装中是预装的）。
现在，cron 文件是空的，以便于从草稿中添加命令。 我增加下面示例中定义的作业到我的 cron 文件中，作为一个快速指南，我知道命令中的各个部分的意思是什么，你可以免费拷贝它，供你自己使用。
```
# crontab -e
SHELL=/bin/bash
MAILTO=root@example.com
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
# For details see man 4 crontabs
# Example of job definition:
# .---------------- minute (0 - 59)
# |  .------------- hour (0 - 23)
# |  |  .---------- day of month (1 - 31)
# |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
# |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# |  |  |  |  |
# *  *  *  *  * user-name  command to be executed
# backup using the rsbu program to the internal 4TB HDD and then 4TB external
01 01 * * * /usr/local/bin/rsbu -vbd1 ; /usr/local/bin/rsbu -vbd2
# Set the hardware clock to keep it in sync with the more accurate system clock
03 05 * * * /sbin/hwclock --systohc
# Perform monthly updates on the first of the month
# 25 04 1 * * /usr/bin/dnf -y update
```
**crontab** 命令是用于去查看或编辑 cron 文件。
上面代码中的前三行，设置了一个缺省环境。环境必须为给定的用户设置，因为，cron 不提供任何方式的环境。**SHELL** 变量指定命令运行使用的 shell。这个示例中，指定为 Bash shell。**MAILTO** 设置发送 cron 作业结果的电子邮件地址。这些电子邮件提供了 cron 作业（备份、更新、等等）的状态，和你从命令行中手动运行程序时看到的结果是一样的。第三行为环境设置了 **PATH**。即使在这里设置了路径，我总是使用每个程序的完全限定路径。
在上面的示例中有几个注释行，它详细说明了定义一个 cron 作业所要求的语法。我将在下面分别讲解这些命令，然后，增加更多的 crontab 文件的高级特性。
```
01 01 * * * /usr/local/bin/rsbu -vbd1 ; /usr/local/bin/rsbu -vbd2
```
这一行是在我的 **/etc/crontab** 中运行一个脚本，用于执行我的系统的备份。
这一行运行我自己编写的 Bash shell 脚本 **rsbu**，它对我的系统做完全备份。这个作业每天的凌晨 1:01 (01 01) 运行。在这三、四、五位置上的星号（*），像文件通配符一样代表一个特别的时间，它们代表 “一个月中的每天”、“每个月” 和 “一周中的每天”，这个行运行我的备份两次，一次备份内部专用的硬盘驱动器，另外一次运行是备份外部的 USB 驱动器，我可以很保险地使用它。
接下来的行设置了一个硬件时钟，它使用当前系统时钟作为源去设置硬件时钟。这一行设置为每天凌晨 5：03 分运行。
```
03 05 * * * /sbin/hwclock --systohc
```
这一行设置硬件时钟使用系统时间作为源。
我使用了一个第三方的，并且是最终版的 cron 作业去执行一个 **dnf** 或 **yum** 更新，它在每个月的第一天的凌晨 04:25 运行，但是，我注释掉它，以后不再运行。
```
# 25 04 1 * * /usr/bin/dnf -y update
```
这一行用于执行一个每月更新，但是，我也把它注释掉了。
### 其它的定时任务技巧
现在，让我们去做一些比基本知识更有趣的事情。假设你希望在每周四下午 3:00 去运行一个特别的作业：
```
00 15 * * Thu /usr/local/bin/mycronjob.sh
```
这一行在每周四下午 3:00 运行 **mycronjob.sh** 这个脚本。
或者，或许你需要在每个季度末去运行一个季度报告。cron 服务没有为 “每个月的最后一天” 设置选项，因此，替代方式是使用下一个月的第一天，像如下所示（这里假设当作业准备运行时，报告所需要的数据已经准备好了）。
```
02 03 1 1,4,7,10 * /usr/local/bin/reports.sh
```
这个 cron 作业运行一个季度报告在季度末的下一个月的第一天。
下面展示的这个作业，在每天的上午 9:01 到下午 5:01 之间，每小时运行一次。
```
01 09-17 * * * /usr/local/bin/hourlyreminder.sh
```
有时，你希望作业在业务期间定时运行。
我遇到一个情况，需要作业在每二、三或四小时去运行。它需要用期望的间隔去划分小时，比如， ***/3** 为每三个小时，或者 **6-18/3** 为上午 6 到下午 6 每三个小时运行一次。其它的时间间隔的划分也是类似的。例如，在分钟位置的表达式 ***/15** 意思是 “每 15 分钟运行一次作业”。
```
*/5 08-18/2 * * * /usr/local/bin/mycronjob.sh
```
这个 cron 作业在上午 8:00 到下午 5:58 之间，每五分钟运行一次作业。
需要注意的一件事情是：分隔表达式的结果必须是剩余运行时间为 0。换句话说，在这个例子中，这个作业被设置为在上午 8 点到下午 6 天之间，每 5 分钟运行一次（08:05、 08:10、 08:15、等等）。例如，这个作业不能运行在下午 9:00 到上午 9:59之间。
我相信，你可以根据这些例子想到许多其它的可能性。
### 限制访问 cron
更多的 Linux 资源
* [Linux 是什么？][1]
* [Linux 容器是什么？][2]
* [现在就去下载：Linux 命令行备忘录][3]
* [高级 Linux 命令备忘录][4]
* [我的最新的 Linux 文章][5]
普通用户使用 cron 访问可能会犯错误，例如，可能导致系统资源（比如内存和 CPU 时间）被耗尽。为避免这种可能的问题， 系统管理员可以通过创建一个**/etc/cron.allow**文件去限制用户访问，它包含了一个可以允许去创建 cron 作业的用户列表。root 用户不能被阻止使用 cron。
通过阻止 non-root 用户创建他们自己的 cron 作业，它可以将 root 用户需要的 cron 作业添加到 root 的 crontab 中， “但是，等等！” 你说，“不能以 root 去运行这些作业？” 不一定。在这篇文章中的第一个示例中，显示在注释中的用户名域可以用于去指定一个运行作业的用户 ID。这防止指定的 non-root 用户的作业作为一个 root 身份去运行。下面的示例展示了一个定义的作业，它以 “student” 用户去运行这个作业：
```
04 07 * * * student /usr/local/bin/mycronjob.sh
```
如果没有指定用户，这个作业将以 contab 文件的所有者用户去运行，在这个案例中是 root。
### cron.d
目录 **/etc/cron.d** 中是一些应用程序，比如，[SpamAssassin][14] 和 [sysstat][15]，安装 cron 文件。因为，这里没有 spamassassin 或者 sysstat 用户，这些程序需要一个位置去定位 cron 文件，因此，它们位于 **/etc/cron.d**中。
**/etc/cron.d/sysstat** 文件下面包含系统活动报告相关的（SAR） cron 作业。这些 cron 文件有和用户 cron 文件相同的格式。
```
# Run system activity accounting tool every 10 minutes
*/10 * * * * root /usr/lib64/sa/sa1 1 1
# Generate a daily summary of process accounting at 23:53
53 23 * * * root /usr/lib64/sa/sa2 -A
```
sysstat 包安装 **/etc/cron.d/sysstat** cron 文件去运行 SAR 程序。
sysstat cron 文件有两行去执行任务。第一行每十分钟去运行 **sa1** 程序去收集数据，存储在 **/var/log/sa** 目录中的一个指定的二进制文件中。然后，在每天晚上的 23:53， **sa2** 程序运行去创建一个每日汇总。
### 计划小贴士
我在 crontab 文件中设置的有些时间看上起似乎是随机的，在某种程度上说，确实是这样的。尝试去安排 cron 作业可能是件很具有挑战性的事， 尤其是，作业的数量越来越多。我通常在每个我的电脑上仅有一些任务，它比起我工作的那些生产和实验环境中的电脑简单多了。
我管理的一个系统有 12 个 cron 作业，每天晚上都运行，另外 3 个或 4 个在周末或第一个月运行。那真是个挑战，因为，如果有太多作业在同一时间运行，尤其是备份和编译系统，会耗尽内存并且几乎填满交换文件空间，导致系统性能下降甚至是超负荷，最终什么事情都完不成。我还删除了一些写的很糟糕、使用大量内存的任务。
crond 服务假设主机计算机 24 小时运行。那意味着如果在一个计划运行的周期中关闭计算机，这些计划的任务将不再运行，直到它们计划的下一次运行时间。如果这里有关键的 cron 作业，这可能导致出现问题。 幸运的是，在定期运行的作业上，还有一个其它的选项： **anacron**。
### anacron
[anacron][16] 程序执行和 cron 一样的功能，但是它增加了跳过的运行作业的可靠性，比如，如果计算机已经关闭或者其它的原因无法去运行一个或多个循环作业。它对笔记本电脑或其它的关闭或进行睡眠模式的电脑来说是非常有用的。
只要电脑一打开或引导成功，anacron 会检查过去是否有计划的作业被错过。如果有，这些作业将立即运行，但是，仅运行一次（而不管它错过了多少次循环运行）。例如，如果一个每周运行的作业在最近三周因为休假系统关闭都没有运行，它将在你的电脑一启动就立即运行，但是，它仅运行一次，而不是三次。
anacron 程序提供了一些对定期计划任务很好用的选项。它是安装在你的 **/etc/cron.[hourly|daily|weekly|monthly]** 目录下的脚本。 根据它们需要的频率去运行。
它是怎么工作的呢？接下来的这些要比前面的简单一些。
1. crond 服务运行在 **/etc/cron.d/0hourly**中指定的 cron 作业。
```
# Run the hourly jobs
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
01 * * * * root run-parts /etc/cron.hourly
```
**/etc/cron.d/0hourly** 中的内容包含了位于 **/etc/cron.hourly** 中的，用于去运行的 shell 脚本。
1. 在 **/etc/cron.d/0hourly** 中指定的 cron 作业每小时运行一次 **run-parts** 程序。
2. **run-parts** 程序运行所有的在 **/etc/cron.hourly** 目录中的脚本。
3. **/etc/cron.hourly** 目录包含的 **0anacron** 脚本，它使用 **/etdc/anacrontab** 配置文件去运行 anacron 程序。
```
# /etc/anacrontab: configuration file for anacron
# See anacron(8) and anacrontab(5) for details.
SHELL=/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
# the maximal random delay added to the base delay of the jobs
RANDOM_DELAY=45
# the jobs will be started during the following hours only
START_HOURS_RANGE=3-22
#period in days   delay in minutes   job-identifier   command
1       5       cron.daily              nice run-parts /etc/cron.daily
7       25      cron.weekly             nice run-parts /etc/cron.weekly
@monthly 45     cron.monthly            nice run-parts /etc/cron.monthly
```
**/etc/anacrontab** 文件中的内容是，在合适的时间运行在 **cron.[daily|weekly|monthly]** 目录中的可执行文件。
1. anacron 程序每日运行一次位于 **/etc/cron.daily** 中的作业。它每周运行一次位于 **/etc/cron.weekly** 中的作业。以及每月运行一次 **cron.monthly** 中的作业。注意，在每一行指定的延迟时间，它可以帮助避免这些作业与其它 cron 作业重叠。
我在 **/usr/local/bin** 目录中安装它们，而不是在 **cron.X** 目录中放置完整的 Bash 程序。它使我从命令行中运行它们更容易。然后，我在 cron 目录中增加一个符号连接，比如，**/etc/cron.daily**。
anacron 程序不是设计用于去在指定时间运行程序的。而是，用于在一个指定的开始时间的去开始，以一定的时间间隔去运行程序，比如，从这周周日开始的每天的凌晨 3:00（看上面脚本中的 **START_HOURS_RANGE** 行），和这个月的第一天。如果任何一个或多个循环错过，anacron 将立即运行这个错过的作业。
### 更多的关于设置限制
我在我的计算机上使用了很多运行计划任务的方法。所有的这些任务都需要一个 root 权限去运行。在我的经验中，很少有普通用户去需要运行 cron 任务，一种情况是开发人员需要一个 cron 作业去启动一个开发实验的每日编译。
限制 non-root 用户去访问 cron 功能是非常重要的。然而，在一些特殊情况下，一个用户需要去设置一个任务在指定时间去运行，而 cron 可以允许他们去那样做。许多用户不理解如何正确地配置 cron 去完成任务，并且让他们不出错。这些错误可能是无害的，但是，经常不是这样，它们可能产生一个问题。通过设置功能策略，使用户与管理员互相配合，使个别的 cron 作业尽可能地不干扰其它的用户和系统功能。
可以给为单个用户或组分配的资源设置限制，但是，这是下一篇文章中的内容。
更多信息，在 [cron][17]、[crontab][18]、[anacron][19]、[anacrontab][20]、和 [run-parts][21] 的 man 页面上，所有的这些信息都描述了 cron 系统是如何工作的。
--------------------------------------------------------------------------------
作者简介：
David Both - 是一位 Linux 和开源软件的倡导者，居住在 Raleigh， North Carolina。他从事 IT 行业超过四十年时候，并且在 IBM 教授 OS/2 超过20年时间，在 IBM 期间，他在1981年，为最初的 IBM PC 写了第一部培训教程。他为 Red Hat 教授 RHCE 系列课程，并且他也为 MCI Worldcom、 Cisco、和 North Carolina 州工作。他使用 Linux 和开源软件工作差不多 20 年了。
---------------------------
via: https://opensource.com/article/17/11/how-use-cron-linux
作者：[David Both ][a]
译者：[qhwdw](https://github.com/qhwdw)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]:https://opensource.com/users/dboth
[1]:https://opensource.com/resources/what-is-linux?intcmp=70160000000h1jYAAQ&utm_source=intcallout&utm_campaign=linuxcontent
[2]:https://opensource.com/resources/what-are-linux-containers?intcmp=70160000000h1jYAAQ&utm_source=intcallout&utm_campaign=linuxcontent
[3]:https://developers.redhat.com/promotions/linux-cheatsheet/?intcmp=70160000000h1jYAAQ&utm_source=intcallout&utm_campaign=linuxcontent
[4]:https://developers.redhat.com/cheat-sheet/advanced-linux-commands-cheatsheet?intcmp=70160000000h1jYAAQ&utm_source=intcallout&utm_campaign=linuxcontent
[5]:https://opensource.com/tags/linux?intcmp=70160000000h1jYAAQ&utm_source=intcallout&utm_campaign=linuxcontent
[6]:https://opensource.com/article/17/11/how-use-cron-linux?rate=9R7lrdQXsne44wxIh0Wu91ytYaxxi86zT1-uHo1a1IU
[7]:https://sourceforge.net/projects/logwatch/files/
[8]:https://github.com/logrotate/logrotate
[9]:http://rkhunter.sourceforge.net/
[10]:https://opensource.com/user/14106/feed
[11]:https://www.flickr.com/photos/internetarchivebookimages/20570945848/in/photolist-xkMtw9-xA5zGL-tEQLWZ-wFwzFM-aNwxgn-aFdWBj-uyFKYv-7ZCCBU-obY1yX-UAPafA-otBzDF-ovdDo6-7doxUH-obYkeH-9XbHKV-8Zk4qi-apz7Ky-apz8Qu-8ZoaWG-orziEy-aNwxC6-od8NTv-apwpMr-8Zk4vn-UAP9Sb-otVa3R-apz6Cb-9EMPj6-eKfyEL-cv5mwu-otTtHk-7YjK1J-ovhxf6-otCg2K-8ZoaJf-UAPakL-8Zo8j7-8Zk74v-otp4Ls-8Zo8h7-i7xvpR-otSosT-9EMPja-8Zk6Zi-XHpSDB-hLkuF3-of24Gf-ouN1Gv-fJzkJS-icfbY9
[12]:https://creativecommons.org/licenses/by-sa/4.0/
[13]:https://en.wikipedia.org/wiki/Cron
[14]:http://spamassassin.apache.org/
[15]:https://github.com/sysstat/sysstat
[16]:https://en.wikipedia.org/wiki/Anacron
[17]:http://man7.org/linux/man-pages/man8/cron.8.html
[18]:http://man7.org/linux/man-pages/man5/crontab.5.html
[19]:http://man7.org/linux/man-pages/man8/anacron.8.html
[20]:http://man7.org/linux/man-pages/man5/anacrontab.5.html
[21]:http://manpages.ubuntu.com/manpages/zesty/man8/run-parts.8.html
[22]:https://opensource.com/users/dboth
[23]:https://opensource.com/users/dboth
[24]:https://opensource.com/article/17/11/how-use-cron-linux#comments