Detailed explanation of the use and precautions of crontab under Linux

crontab is an instruction that is set to be executed periodically. Its daemon is crond. crontab is divided into two configuration modes, one is crontab at user level and one is crontab at system level, which we will talk about separately here.

User-level crontab

When users use the new circular work scheduling, the crontab command, crontab-e can be used by all users, and ordinary users can only set scheduled tasks for themselves. It then writes/var/spool/cron/usename automatically

User control file

/etc/cron. allow:
Write users who can use crontab, and only users in this file can use crontab, which is equivalent to a white list

/etc/cron. deny:
Users who use crontab will be prohibited from writing, and only users in this file will be prohibited from using crontab, which is equivalent to a blacklist
Among them, the/etc/cron. allow has greater priority than the/etc/cron. deny. To avoid confusion, it is recommended to use only one of the two.

Command

crontab [-u usename] [-l|-e|-r] 
 Parameters:  
-u : Only root To perform this task, that is, to create a new one for other users / Delete crontab Work scheduling  
-e:  Call vi Edit crontab The work content of  
-l:  List crontab The work content of  
-r:  Delete all crontab The work content. 

Grammar

# .----------------  Minutes  (0 - 59) 
# | .-------------  Hours  (0 - 23)
# | | .----------  Date  (1 - 31)
# | | | .-------  Month  (1 - 12) OR jan,feb,mar,apr ...
# | | | | .----  Day of the week  (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# | | | | |
# * * * * *  Command 

The syntax is similar to system-level crontab, except that there is no need to specify an execution user here, but it is required in system-level crontab (/etc/crontab).

Examples are as follows:

*/10 * * * * /home/test.sh   # Every interval 10 Minutes as the current user 1 Times /home/test.sh Script 
0 2 * * * /home/test.sh     # Every day 2 Point  
0 5,17 * * * /home/test.sh   # Every day 5 Point, 17 Point 
0 17 * * sun /home/test.sh   # Every Sunday 17 Point 
0 4,17 * * sun,mon /home/test.sh# Weekly 1.  Sunday 
@reboot /home/test.sh      # When the system restarts, 

An online gadget is recommended here: generate cron expressions online

System level crontab

System-level crontab1 is generally used for routine tasks of the system. This method is more convenient and directly sets scheduled tasks for other users, and can also specify to execute shell and so on. The configuration file is/etc/crontab, which can only be edited by root users.

Edit/etc/crontab

The default content is as follows:

SHELL=/bin/bash   This specifies which type to use shell Interface  
PATH=/sbin:/bin:/usr/sbin:/usr/bin  The file lookup path is specified here  
MAILTO=root              If there are extra STDOUT , to email To whom to send the data, you can specify the system user or specify email Address, such as alliot@iots.vip
# For details see man 4 crontabs
# Example of job definition:
# .----------------  Minutes  (0 - 59) 
# | .-------------  Hours  (0 - 23)
# | | .----------  Date  (1 - 31)
# | | | .-------  Month  (1 - 12) OR jan,feb,mar,apr ...
# | | | | .----  Day of the week  (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# | | | | |
# * * * * *  User name   Command 

Namely:

Execute user task commands in time-sharing days, months and weeks

For example, if I want to add a scheduled task that executes the home/test. sh script every 10 minutes/home/test/sh, then add:

*/10 * * * * root /home/test.sh

Be careful here not to leave out the executor root (you don't need to specify an executor in the user-level crontab), otherwise an "ERROR (getpwnam () failed)" error will appear in the/var/log/cron log, and the scheduled task will not work properly.

Restart service

Generally speaking, crontab under Linux will automatically help us re-read the routine work items of/etc/crontab once every minute. However, for some reasons or in other Unix systems, because crontab is read into memory, it may not be executed immediately after modification/etc/crontab, so it is necessary to restart crontab service at this time.

Take CentOS as an example:

service crond start  // Startup service  
service crond stop   // Shut down the service  
service crond restart // Restart service  
service crond reload  // Overloaded configuration  
service crond status  // Service status 

In case of CentOS 7:

systemctl restart crond.service // Restart service  
systemctl start crond.service  // Startup service  
systemctl stop crond.service  // Stop service  
systemctl reload crond.service // Overloaded configuration  
systemctl status crond.service // Service status 

Other matters needing attention

Cancel Unwanted Output

When there is output data in the execution result or the execution option, the data will be sent to the account specified by MAILTO through mail. If there is a direct error in one dispatcher and there is a problem in mail service (in fact, I didn't open this service at all), a large number of files will be generated in/var/spool/clientmqueue/, so it is best to add the command in crontab > /dev/null 2 > & 1

2 > : Redirect error.
2 > & 1: Redirect the error to where the output is to be sent. That is to say, the execution result of the above command is redirected to/dev/null, that is, discarded, and at the same time, the generated errors are also discarded.

Check the log

The log is saved in/var/log/cron

Grammatical distinction

The crontab-e command checks the syntax, while the vim edit/etc/crontab does not. Note here that crontab-e does not need to write the performer username, whereas/etc/crontab needs to be specified. The execution path must use an absolute path, otherwise it may not execute normally. Week can't coexist with day and month, that is, you can cycle in units of week or day and month respectively, but you can't specify the mode of "what day of the month and what day of the week".

References

Brother Bird's Linux Private Kitchen