Crontab error analysis and reasons for not executing

Cron
Cron is a time-based job scheduler in Unix-like computer operating systems.The name cron comes from the world chronograph(a time-piece).
Cron enables users to schedule jobs(commands or shell scripts)to run automatically at a certain time or date.It is commonly used to automate system maintenance or administration,though its general purpose nature means that it can be used for other purposes,such as connecting to the Internet and downloading email.

In fact, I think one of the most common problems with Crontab is often because of the wrong environment variables . I often see people in the forum asking: Why is my Crontab created and not executed? When preparing to create a Cron JOB, many people like to run it on the command line, because at this time the environment variables are automatically brought in with the Shell, In Crontab, the JOB may not be executed because the correct environment variables cannot be found. This small problem is like a smallpox, and it is remembered after a lesson.

A trick that must be used
After each JOB is executed, the system will automatically send the output to the current system user. Over time, there will be a lot, and it will even burst the entire system. So it is very necessary to perform redirection processing after each JOB command: >/dev/null 2>&1 . The premise is that the normal output of the commands in the Job has been processed to a certain extent, such as appending to a specific log file.

1. Edit directly with crontab command

The cron service provides the crontab command to set the cron service. The following are some parameters and descriptions of this command:

crontab -u //Set the cron service of a user, generally the root user needs this parameter when executing this command

crontab -l //List the details of a user's cron service

crontab -r //delete cron service without a user

crontab -e //Edit a user's cron service

For example, root to view its own cron settings: crontab -u root -l

For another example, root wants to delete fred's cron settings: crontab -u fred -r

When editing a cron service, the edited content has some formats and conventions, enter: crontab -u root -e

Enter the vi editing mode, the edited content must conform to the following format: */1 * * * * ls >> /tmp/ls.txt

The first part of this format is the time setting, and the latter part is the command to be executed. If there are too many commands to be executed, these commands can be written into a script, and then the script can be called directly here. Remember to write the full path of the command when We have a certain convention for the setting of time. The first five * signs represent five numbers. The value range and meaning of the numbers are as follows:

minutes (0-59)

hours (0-23)

Date (1-31)

Month (1-12)

Week (0-6) // 0 means Sunday

In addition to numbers, there are several special symbols such as "*", "/" and "-", ",", * represents all numbers within the range of values, "/" represents the meaning of each, "*/5 " means every 5 units, "-" means from a certain number to a certain number, "," separates several discrete numbers. Here are a few examples to illustrate the problem:

every morning at 6 am

0 6 * * * echo "Good morning." >> /tmp/test.txt //Note that just echo, you can't see any output from the screen, because cron emails any output to root's mailbox.

every two hours

0 */2 * * * echo “Have a break now.” >> /tmp/test.txt

Every two hours between 11pm and 8am, at 8am

0 23-7/2，8 * * * echo “Have a good dream：）” >> /tmp/test.txt

4th of every month and every Monday to Wednesday at 11:00 am

0 11 4 * 1-3 command line

January 1st at 4 am

0 4 1 1 * command line

Every time after editing a user's cron settings, cron automatically generates a file with the same name as the user under /var/spool/cron. The user's cron information is recorded in this file. This file cannot be edited directly. Yes, it can only be edited with crontab -e. After cron is started, read this file every hour to check whether the commands in it are to be executed. Therefore, it is not necessary to restart the cron service after this file is modified.

2. Edit the /etc/crontab file to configure cron

The cron service not only needs to read all the files in /var/spool/cron once per minute, but also needs to read /etc/crontab once, so we configure this file to also use the cron service to do some things. Configuring with crontab is for a user, while editing /etc/crontab is a system-specific task. The file format of this file is:

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root //If there is an error, or there is data output, the data will be sent to this account as an email
HOME=/ //Use The path where the operator runs, here is the root directory
# run-parts
01 * * * * root run-parts /etc/cron.hourly //Execute the script in /etc/cron.hourly every hour
02 4 * * * root run- parts /etc/cron.daily //Execute script 22 in /etc/cron.daily every day 4 * * 0 root run-parts /etc/cron.weekly //Execute script 42
in /etc/cron.weekly every week
4 1 * * root run-parts /etc/cron.monthly //Execute the script in /etc/cron.monthly every month

Everyone pay attention to the "run-parts" parameter. If you remove this parameter, you can write the name of a script to be run instead of the folder name.

Reference:
http://en.wikipedia.org/wiki/Crontab
http://www.dbanotes.net/techmemo/crontab_tips.html

Crontab error analysis and reasons for not executing

Crontab error analysis and reasons for not executing

Guess you like