Detailed explanation of the use and precautions of crontab under Linux

Crontab is a command used to set up periodic execution. Its daemon process is crond. There are two configuration modes of crontab, one is user-level crontab and the other is system-level crontab. We will discuss them separately here.

User level crontab

When users create a new cyclic job schedule, the crontab command used, crontab -e, is available to all users. Ordinary users can only set scheduled tasks for themselves. Then automatically write to /var/spool/cron/usename

User Control File

/etc/cron.allow :
Write the users who can use crontab. Only the users in this file can use crontab, which is equivalent to a whitelist.

/etc/cron.deny :
Write the users who are prohibited from using crontab. Only the users in this file are prohibited from using crontab, which is equivalent to a blacklist. /etc/cron.allow has a higher priority than /etc/cron.deny. To avoid confusion, it is recommended to use only one of them.

Order

crontab [-u usename] [-l|-e|-r] 
parameter: 
-u: Only root can perform this task, that is, to help other users create/delete crontab work scheduling -e: Call vi to edit the work content of crontab -l: List the work content of crontab -r: Delete all crontab work contents.

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
# | | | | |
# * * * * * Order

The syntax is very similar to the system-level crontab, the difference is that there is no need to specify the execution user here, while it is required in the system-level crontab (/etc/crontab).

Here are some examples:

*/10 * * * * /home/test.sh #Execute the /home/test.sh script as the current user every 10 minutes 0 2 * * * /home/test.sh #Every day at 2 o'clock 0 5,17 * * * /home/test.sh #Every day at 5 o'clock and 17 o'clock 0 17 * * sun /home/test.sh #Every Sunday at 17 o'clock 0 4,17 * * sun,mon /home/test.sh #Every Monday and Sunday @reboot /home/test.sh #When the system restarts

Here is an online tool recommended: Generate cron expressions online

System-wide crontab

System-level crontab is generally used for routine tasks of the system. This method is more convenient and direct to set scheduled tasks for other users, and can also specify the execution of shells, etc. The configuration file is /etc/crontab, which can only be edited by the root user.

Edit /etc/crontab

The default content is as follows:

SHELL=/bin/bash This is to specify which shell interface to use PATH=/sbin:/bin:/usr/sbin:/usr/bin This is to specify the file search path MAILTO=root If there is an additional STDOUT, to whom the data is sent by email, you can specify a system user or an email address, such as [email protected]
# 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
# | | | | |
# * * * * * Username command

Right now:

Execute user task commands in daily, monthly and weekly time periods

For example, if I want to add a scheduled task to execute the /home/test.sh script as root every 10 minutes, I would add:

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

Note that you should not omit the executor root (the executor does not need to be specified in the user-level crontab). Otherwise, an error "ERROR (getpwnam() failed)" will appear in the /var/log/cron log, and the scheduled task will not run properly.

Restart the service

Generally speaking, crontab under Linux will automatically re-read the routine tasks in /etc/crontab every minute. However, for some reasons or in other Unix systems, crontab is read into the memory, so after modifying /etc/crontab, it may not be executed immediately. At this time, you need to restart the crontab service.

Here we take CentOS as an example:

service crond start //Start the service service crond stop //Shut down the service service crond restart //Restart the service service crond reload //Reload the configuration service crond status //Service status

If it is CentOS 7:

systemctl restart crond.service //Restart servicesystemctl start crond.service //Start servicesystemctl stop crond.service //Stop servicesystemctl reload crond.service //Reload configurationsystemctl status crond.service //Service status

Other considerations

Suppress unwanted output

When there is output data in the execution results or execution options, the data will be sent to the account specified by MAILTO via mail. If a certain schedule keeps failing and there is a problem with the mail service (in fact, I don’t have this service turned on at all), a large number of files will be generated in /var/spool/clientmqueue/, so it is best to add > /dev/null 2>&1 after the command in crontab

2>: Redirection error.
2>&1: Redirect errors to where output should go. That is, redirect the execution result of the above command to /dev/null, that is, discard it, and at the same time, discard the generated errors.

Check the logs

Logs are saved in /var/log/cron

Grammatical Differences

• The crontab -e command will check the syntax, while vim editing /etc/crontab will not. Note that crontab -e does not require the executor username, while /etc/crontab needs to be specified.
• The execution path must use an absolute path; otherwise, the execution may not proceed normally.
• Weeks, days and months cannot coexist, that is, you can cycle by week, day or month, but you cannot specify a "day of the month and day of the week" mode.

References

Bird Brother's Linux Private Kitchen

The above is the full content of this article. I hope it will be helpful for everyone’s study. I also hope that everyone will support 123WORDPRESS.COM.