Contents of this article:

12.1 Configure Timer Tasks

12.2 crontab file

Debugging 12.3 crond command

12.4 Task Schedule Accurate to Seconds

12.1 Configure Timer Tasks

First, you need to understand the concepts:

(1).crond is a daemon class program with a path of / usr/sbin/crond.The default will start in background mode, and crond will start in service or systemd mode by default.

(2).crondtab is a tool for managing crontab files, and crontab files are files that define timed task entries.

(3). crontab files exist in many places, including system timer task files/etc/crontab and/etc/cron.d/*, as well as task files/var/spool/cron/USERNAME that are unique to each user.

Then the crontab command:

-l: List timed task entries
 -r: Delete all task entries at the end of the current task list
 -i: Prompt if you really want to delete an entry when deleting it
 -e: Edit the timer task file, actually the / var/spool/cron/* file
 -u: Operates a timed task for a specified user

Execute the crontab-e command to edit the crontab file of the current user, such as the current root user, then edit the / var/spool/cron/root file.For example, write this line below.

* * * * * /bin/echo "the first cron entry"  >>/tmp/crond.txt

This will execute echo commands every minute, appending the contents to the / tmp/crond.txt file.

You can view the / etc/crontab file for how task entries in a task plan are defined.

There are three variables defined in this file, one of which is PATH, which is extremely important.In the end, the way task entries are defined is also given:

(1) Each task entry is divided into six segments, each separated by spaces. The reason why there are more user-name segments here is that/etc/crontab is the system timed task file, which is not used for regular timed tasks.

(2) The first five paragraphs are time-sharing periods, which represent "time-sharing days, months and weeks". Their definitions cannot exceed reasonable values. The sixth paragraph is the command or script task segment to be executed.

(3). In the time definition period, use'*'to indicate each unit, i.e., minute, hour, day, month, day of week (still a day).

(4). Commas can be used to denote enumerations for each time period, such as defining "0,30,50 * * *" to denote that the task is performed at the same time, in the 30th and 50th minutes of each time period.

(5). For each time period, you can use'-'to define ranges, which can be combined with commas.If a minute period defines "00,20-30,50", it means that the task is performed at the full time of each hour, every minute of the 20th to 30th minutes, and the 50th minute.

(6). For each time period, use'/'to denote ignorance time, such as the definition of'0-13/2' in the hour period to denote that the time definition is satisfied at'0/2/4/6/8/10/12'point.The term'*/N'is often used to indicate how often it means.For example, "00 */2 * * *" means that the task is performed every two hours of the day at an hour.

(7). If a day and week conflict is defined, it will be executed multiple times (excluding conflicts caused by *).For example, the task is performed on the 15th day of the month, while Wednesday is defined to perform the task. Normally, without conflict, it will be performed on Wednesday and 15th of the month, but if the 15th day of the month is Wednesday at the same time, the task will be performed twice that day.Therefore, every effort should be made to avoid tasks that define both weekdays and days.

(8). In the command paragraph (that is, paragraph 6), the percentage sign'%'cannot appear at will, because it indicates the special meaning of a line break, and all strings after the first% will be used as standard input for the command.

For example, the following definitions:

* * * * * /bin/cat >>/tmp/crond.txt %"the first %%cron entry%"

The output of this task will be:

"the first

cron entry
"

Therefore, when defining the file name as time in the timed task entry, you should escape% with a backslash.For example:

* * * * * cp /etc/fstab /tmp/`date +\%Y-\%m-\%d`.txt

Another time period setting to be aware of is that the use of the * sign results in lower levels of time covering higher levels of time.For example,'* */2 * * * *', does not mean a task is executed every two hours, but every minute. Although every two hours is set on the hour bit, every minute is set on the minute bit, so it still means a task is executed every minute.Similarly, the setting on the'*/5 */2 * * * *'minute bit overrides the setting on the hour bit, meaning that the setting on the hour bit is ignored when executed every 5 minutes; and'00 */2 */5 * *' means that the task is executed every two hours at the whole point, ignoring the setting on the day bit.

12.2 crondtab file

crondtab file is the task definition file.

(1). In this file, blank lines are ignored. The first non-blank character that starts with a # annotates the line, but # cannot appear on the line.

(2). Environment variables can be set in crontab file in the form of "name=value", and the spaces on either side of the equal sign are optional, that is, "name=value" is also allowed.However, the spaces that appear in the value must be surrounded by quotation marks.

(3). All variables are initialized when the default crond command starts, and all variables are set to null values except for a few that are automatically set by crond daemon.Automatically set variables include SHELL=/bin/sh, and HOME and LOGNAME (called USER on CentOS), which are set by default to the values specified in/etc/passwd.SHELL and HOME can be overridden by custom variables in crontab file, but LOGNAME does not allow overwriting.Of course, self-defined variables are also loaded into memory.

(4). In addition to the LOGNAME/HOME/SHELL variable, crond also looks for the MAILTO variable if Send Mail is set.If MAILTO is set, the message will be sent to the address specified by this variable. If the value defined by MAILTO is empty (MAILTO="), the message will not be sent and in all other cases the message will be sent to the owner of the crontab file.

(5). In the system timer task file/etc/crontab, PATH environment variables and SHEL environment variables are defined by default, where PATH=/sbin:/bin:/usr/sbin:/usr/bin.

(6).crond daemon detects the crontab file every minute to see if there are any task plan entries to execute.

Debugging 12.3 crond command

Many times a timed task is written and found not to be executed or failed to execute, but because crond is running in the background, it is difficult to troubleshoot it without any hints.But you can have crond run on the front end and debug it.

Explain the default execution of the task scheduler crond below.

The crond started with the following three commands runs in the background and is not dependent on the terminal.

However, crond is allowed to accept options.

crond [-n] [-P] [-x flags]
Option description:
-n: Let crond run in front-end mode, i.e. independent of the terminal.
-P: Do not reset the environment variable PATH, but inherit from the parent process.
-x: Set up debugging items, flags is the way to debug, and the more useful ways are test and sch,'-x test'and'-x sch'.
  : where test debugging will not actually execute, sch debugging will see the wait time.See the example below for details.

First, see how the startup script starts crond.

Its environment profile is/etc/sysconfig/crond, and nothing is set in it.

All its startup commands are: /usr/sbin/crond-n.However, although the'-n'option is added here, crond will not run on the front end and will not depend on the terminal, as determined by systemctl.

How to debug under explanation.Take the task entry below for example.

Execute crond with the debug option test.

Execute crond with the debug option sch.

Note, however, that the wait time in the sch debugging results is crond, the daemon's detection time, so it represents the time to wait for the next detection, so every time except the first, it is 60 seconds since the default crond detects crontab file s every minute.For example, here is the result of a wait that did not perform any tasks during the wait detection process.

[4937] Target time=1497951720, sec-to-wait=18
[4937] Target time=1497951780, sec-to-wait=60
[4937] Target time=1497951840, sec-to-wait=60

You can also debug in multiple ways at the same time, such as:

This will not actually execute the command when debugging the timed task time.

12.4 Task Schedule Accurate to Seconds

By default, crond can only perform tasks as precise as minutes, not seconds.But by skill, you can also accomplish second-level tasks.

Method 1: less precise method

Write a script that sleeps for 3 seconds in the script so that commands can be executed every 3 seconds.

However, this is not the best method because executing commands also takes time, and crond has a random delay by default, which is defined by the variable RANDOM_DELAY.

(2) Method 2: Write several sleep commands and other commands in the cron configuration file.

This is cumbersome but more accurate.If defined to a level per second, 60 rows of cron records must be written.

As you can see, second-level tasks are not what crond is good at.There are actually fewer tasks that can be used in seconds.

Back to the series article outline: http://www.cnblogs.com/f-ck-need-u/p/7048359.html

For reprinting, please indicate the source: http://www.cnblogs.com/f-ck-need-u/p/7059418.html