01. Knowledge about timing tasks
The linux system is controlled by the cron (crond) system service. There is a lot of planned work on the Linux system, so this system service is started by default . In addition, since users can also set up scheduled tasks, the Linux system also provides users with commands to control scheduled tasks, the crontab command.
01. Introduction to crond
Crond is a daemon process used to periodically perform certain tasks or wait for certain events under Linux . When the operating system is installed, this service tool will be installed by default, and the crond process will be automatically started . The crond process will be executed every minute Regularly check whether there is a task to be performed, and if there is a task to be performed, the task will be executed automatically.
Task scheduling under Linux is divided into two categories, system task scheduling and user task scheduling .
System task scheduling : tasks to be performed by the system periodically, such as writing cached data to the hard disk, log cleaning, etc. There is a crontab file in the /etc directory, which is the configuration file for system task scheduling.
[root@ufo130 ~]# cat /etc/crontab
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/
# 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
The first four lines configure the environment variables for the crond task to run:
- The SHELL variable specifies which shell the system will use, here is bash
- The PATH variable specifies the path where the system executes the command
- The MAILTO variable specifies that the task execution information of crond will be sent to the root user via email. If the value of the MAILTO variable is empty, it means that the task execution information will not be sent to the user
- The HOME variable specifies the home directory used when executing commands or scripts
The specific task configuration of the crontab file:
In the crontab file, each line represents a task, and each field in each line represents a setting. Its format is divided into six fields. The first five sections are the time setting section, and the sixth section is the command to be executed. Paragraph, the format is as follows:
in each of the above fields, the following special characters can also be used:
-
Asterisk (*): Represents all possible values. For example, if the month field is an asterisk, it means that the command operation will be executed every month after meeting the constraints of other fields.
-
Comma (,): You can specify a list range with comma-separated values, for example, "1,2,5,7,8,9"
-
Middle bar (-): A middle bar between integers can be used to represent an integer range, for example, "2-6" means "2,3,4,5,6"
-
Forward slash (/): You can use forward slashes to specify the time interval frequency, for example, "0-23/2" means that it will be executed every two hours. At the same time, the forward slash can be used with an asterisk, such as */10, if used in the minute field, it means that it will be executed every ten minutes
User task scheduling : tasks that users need to perform regularly, such as user data backup, regular email reminders, etc. Users can use the crontab tool to customize their own scheduled tasks. All user-defined crontab files are stored in the /var/spool/cron directory. The file name is consistent with the user name .
Permission restriction file:
- /etc/cron.deny The users listed in this file are not allowed to use the crontab command
- /etc/cron.allow The users listed in this file are allowed to use the crontab command
- /var/spool/cron/ The directory where all users crontab files are stored, named after the user name
02. crond service
Install crontab:
yum install crontabs
Service operation instructions:
/sbin/service crond start
# 启动服务
/sbin/service crond stop
# 关闭服务
/sbin/service crond restart
# 重启服务
/sbin/service crond reload
# 重新载入配置
/sbin/service crond status
# 启动服务
Check whether the crontab service has been set to start at boot, execute the command:
ntsysv
Join to start automatically at boot:
chkconfig -level 35 crond on
Through the crontab command, we can execute specified system commands or shell script scripts at regular intervals. The unit of the time interval can be any combination of minutes, hours, days, months, weeks and above. This command is very suitable for periodic log analysis or data backup.
Command format:
crontab [-u user] file
crontab [-u user] [ -e | -l | -r ]
Command parameters:
-
-u user: used to set the crontab service of a user, for example, "-u ixdba" means to set the crontab service of the ixdba user, this parameter is generally run by the root user.
-
file: file is the name of the command file, which means to use file as a crontab task list file and load crontab. If this file is not specified on the command line, the crontab command will accept commands typed on standard input (keyboard) and load them into crontab.
-
-e: Edit the content of a user's crontab file. If you do not specify a user, it means to edit the crontab file of the current user.
-
-l: Display the content of the crontab file of a user. If the user is not specified, it means that the content of the crontab file of the current user is displayed.
-
-r: Delete a user's crontab file from the /var/spool/cron directory. If no user is specified, the current user's crontab file will be deleted by default.
-
-i: Give confirmation prompt when deleting user's crontab file
Backup user's crontab file for scheduled tasks:
$ crontab -l > $HOME/用户名
Recover crontab files lost by users
$ crontab <filename>
Example 1: Execute command every 1 minute
* * * * * command
Example 2: Execute at the 3rd and 15th minutes of every hour
3,15 * * * * command
Example 3: Execute at the 3rd and 15th minutes from 8 am to 11 am
3,15 8-11 * * * command
Example 4: Execute at the 3rd and 15th minutes from 8 am to 11 am every two days
3,15 8-11 */2 * * command
Example 5: Execute on the 3rd and 15th minutes from 8 am to 11 am every Monday
3,15 8-11 * * 1 command
Example 6: Restart smb at 21:30 every night
30 21 * * * /etc/init.d/smb restart
Example 7: Restart smb at 4:45 on the 1, 10, and 22 of each month
45 4 1,10,22 * * /etc/init.d/smb restart
Example 8: Restart smb at 1:10 every Saturday and Sunday
10 1 * * 6,0 /etc/init.d/smb restart
Example 9: Restart smb every 30 minutes between 18:00 and 23:00 every day
0,30 18-23 * * * /etc/init.d/smb restart
Example 10: Restart smb every Saturday at 11: 00 pm
0 23 * * 6 /etc/init.d/smb restart
Example 11: Restart smb every hour
* */1 * * * /etc/init.d/smb restart
Example 12: Between 11pm and 7am, restart smb every hour
* 23-7/1 * * * /etc/init.d/smb restart
Example 13: Restart smb on the 4th of every month and 11 o’clock every Monday to Wednesday
0 11 4 * mon-wed /etc/init.d/smb restart
Example 14: Restart smb at 4 on January 1st
0 4 1 jan * /etc/init.d/smb restart
Example 15: Execute the script in the /etc/cron.hourly directory every hour
01 * * * * root run-parts /etc/cron.hourly
Description : run-parts parameter, if you remove this parameter, you can write the name of a script to be run later instead of the directory name
03. Matters needing attention
Pay attention to environmental variables
Sometimes we create a crontab, but this task cannot be executed automatically, and there is no problem in manually executing this task. This situation is generally caused by the fact that there is no environment variable configured in the crontab file.
When defining multiple scheduling tasks in the crontab file, one issue that needs special attention is the setting of environment variables, because when we manually execute a task, it is performed in the current shell environment. Of course, the program can find the environment variables, and the system When task scheduling is executed automatically, no environment variables will be loaded . Therefore, you need to specify all the environment variables required for task operation in the crontab file, so that there is no problem when the system executes task scheduling.
Don't assume that cron knows the special environment it needs, it doesn't. So you have to ensure that all necessary paths and environment variables are provided in the shelll script, except for some automatically set global variables. So pay attention to the following 3 points:
-
Write the global path when the file path is involved in the script;
-
When java or other environment variables are used for script execution, use the source command to introduce environment variables, such as:
cat start_cbp.sh
#!/bin/sh
source /etc/profile
export RUN_CONF=/home/d139/conf/platform/cbp/cbp_jboss.conf
/usr/local/jboss-4.0.5/bin/run.sh -c mev &
- When the script is executed manually, but the crontab is not executed. At this time, you must boldly suspect that the environment variables are the fault, and you can try to directly introduce environment variables in crontab to solve the problem. Such as:
0 * * * * . /etc/profile;/bin/sh /var/www/java/audit_no_count/bin/restart_audit.sh
Pay attention to cleaning up the mail log of system users
After each task is scheduled and executed, the system will send the output information of the task to the current system user in the form of e-mail. This way, the log information will be very large over time, which may affect the normal operation of the system. Therefore, each task is redirected Handling is very important.
For example, you can set the following format in the crontab file to ignore the log output:
0 */3 * * * /usr/local/apache2/apachectl restart >/dev/null 2>&1
"/Dev/null 2>&1" means that standard output is redirected to /dev/null first, and then standard error is redirected to standard output. Since standard output has been redirected to /dev/null, standard error will also be redirected Direct to /dev/null, so the log output problem is solved.
System-level task scheduling and user-level task scheduling
System-level task scheduling mainly completes some maintenance operations of the system, and user-level task scheduling mainly completes some user-defined tasks. User-level task scheduling can be placed in system-level task scheduling to complete (this is not recommended), but the reverse No, the task scheduling operation of the root user can be set by "crontab -uroot -e", or the scheduled task can be directly written into the /etc/crontab file. It should be noted that if you want to define a task that restarts the system regularly, The task must be placed in the /etc/crontab file, even if a task to restart the system periodically is created under the root user, it is invalid.
Other considerations
The newly created cron job will not be executed immediately, and it will take at least 2 minutes to execute. If you restart cron, it will be executed immediately.
When crontab fails suddenly, you can try /etc/init.d/crond restart to solve the problem. Or check the log to see if a job has been executed/error reported tail -f /var/log/cron.
Do not run crontab -r randomly. It deletes the user's crontab file from the crontab directory (/var/spool/cron). All crontabs of this user are gone.
% In crontab has a special meaning, meaning a newline. If you want to use it, you must escape %. For example, the frequently used date'+%Y%m%d' will not be executed in crontab and should be replaced with date'+%Y%m%d'.
Production environment example
- Print the pinyin of your name to "/server/log/file named after yourself" every minute.
#echo my name to /server/log/lt.log
* * * * * echo oldboy >>/server/log/lt.log
- Professional writing of timed tasks in production environment.
Tip 1: Add necessary comments for the timing task rules, preferably in English;
Tip 2: Add /bin/sh before executing the shell script task; otherwise, you may not be able to complete the task because you forgot to set the execution permission x for the steps.
Tip 3: Add >/dev/null 2>&1 to the end of the timed task; equivalent to 1>/dev/null 2>/dev/null
Tip 4: To execute commands with more than 2 lines, it is best to use a script file.
Key 5: Perform related timing tasks under the designated user.
[root@jackroo spool]# crontab -u oldboy -l
no crontab for oldboy
- Key 6: Do not print out information randomly in the production task program.
Essentials 7: The script executed by the timed task should standardize the path.
Essentials 8: Configure the regular operation process of timed tasks.
1）首先要在命令行操作成功，然后复制成功的命令到脚本里，在各个细小环节减少出错的机会。
2）然后测试脚本，测试成功后，复制脚本到定时任务配置里，不要手敲。
3）先在测试环境下测试，然后正式环境规范部署。
- Too many files in /var/spool/clientmqueue cause the inode to be exhausted. no space left on device. Where did so many files come from? Timing task is not added>/dev/null 2>&1
04. Other services (atd, anacron)
Temporary, one-off timing tasks can use the at command, but the atd service needs to be installed, which is not commonly used .
If our Linux host is turned on 24 hours a day and all year round, we only need the two services of atd and crond. If our server does not start up 24 hours a day, then we need the help of anacron.
The anacron service does not replace cron to run a certain task, but takes the day as a unit or immediately performs anacron action after startup. It will detect crontab tasks that should be performed but not performed during the downtime, and then the task After running it again, anacron will automatically stop, which is not commonly used .
Anacron will detect crontab tasks that are not performed in the system in a one-day, seven-day, and one-month cycle, so it is very helpful for some special use environments. Anacron will go to analyze the current time and the time of the last run of anacron recorded in the time log. If the two are thicker, if there is a difference, that is, there is no crontab at some point, then anacron will start to execute The crontab is not running anymore. So anacron also listens to crontab to run, so anacron usually runs two times, one is running during system startup, and the other is writing to crontab schedule, so that it can analyze the crontab work that the system has not performed at a specific time. We can use ll /etc/cron*/*ana* to view the detection time of anacron.