Analysis of non-execution of crontab task plans in Linux

Crond is a daemon in Linux that is used to periodically execute a task or wait for processing some events. It is similar to a scheduled task in windows. After the operating system is installed, by default, the service tool is installed and the crond process is automatically started. The crond process regularly checks whether there are tasks to be executed every minute. If there are tasks to be executed, the task is automatically executed.

Permission:

Owner of the root user and crontab file
Syntax:

Crontab [-e [UserName] |-l [UserName] |-r [UserName] |-v [UserName] | File]

Note:

Crontab is used to allow users to execute programs at a fixed time or interval. In other words, it is similar to the user's time table. -U user is used to set the time table of the specified user. The premise is that you must have the permission (for example, root) to specify the time table of another user. If-u user is not used, the time table is set.

Parameters:

-E [UserName]: run the text editor to set the time table. The preset text editor is VI. If you want to use another text editor, set the VISUAL environment variable to specify the text editor (for example, setenv VISUAL joe)
-R [UserName]: deletes the current time table.
-L [UserName]: list the current time series table
-V [UserName]: lists the statuses of user cron jobs.

The self-pulling script is simple. Just write a few lines:

Shell

#! /Bin/bash
Processcount = $ (pgrep my_app | wc-l)
Cd $ (dirname $0) & pwd)
If [[0-eq $ processcount]
Then
Echo "[$ (date)]: my_app is down, start it! "| Tee-ai./checkprocess. log
Bash./start. sh # The restart script of the project.
Else
Echo my_app is OK!
Fi
Then drop it to crontab and execute it once every minute:
Shell

* *** Bash/data/app_server/checkprocess. sh>/dev/null 2> & 1
I thought everything was done, but the result was still Pitfall. The process crashed again. What the hell is Nima?

I. Check logs

Based on experience, let's take a look at the crontab log:
Tail/var/log/messages
No logs are found. It seems that this is not printed, so the default log location of crontab is viewed:
Tail/var/log/cron

Mar 25 21:40:01 li733-135 CROND [1959]: (root) CMD (sh/data/app_server/checkprocess. sh>/dev/null 2> & 1)
Mar 25 21:40:01 li733-135 CROND [1960]: (root) CMD (/usr/lib64/sa/sa1 1)
Mar 25 21:40:01 li733-135 CROND [1961]: (root) CMD (/usr/sbin/ntpdate pool.ntp.org>/dev/null 2> & 1)
Mar 25 21:41:01 li733-135 CROND [2066]: (root) CMD (sh/data/app_server/checkprocess. sh>/dev/null 2> & 1)

Obviously, the task plan is indeed running normally. It seems that the problem is on the script.

II. Check the script

1. Direct execution

Check the script step 1 and execute the script directly according to the command line in crontab:

Sh/data/app_server/checkprocess. sh
[Fri Mar 25 21:25:01 CST 2016]: my_app is down, start it!
 
Sh/data/app_server/checkprocess. sh
My_app is OK!

The process is pulled up normally!
The execution is successful directly, but it fails to be put into crontab. Experience tells me that the script environment variable is correct!

②. Environment variables

So load the environment variable in the script:

#! /Bin/bash
# Load environment variables first
Source/etc/profile
# Other codes remain unchanged
Then, manually kill the process and wait for the self-pulling process to start. The result is still not correct!
③. System Email

Experience tells me that crontab execution fails. If the error is not blocked, a system email will be generated,
Location:/var/spool/mail/root
Therefore, I canceled the 2> & 1 blocking error in crontab and waited several minutes to view the email.
Cat/var/spool/mail/root found the following error:
 

From root@free-node-us.localdomain Fri Mar 25 21:30:02 2016
Return-Path: <root@app_server.localdomain>
X-Original-To: root
Delivered-To: root@app_server.localdomain
Received: by app_server.localdomain (Postfix, from userid 0)
Id 78DB5403E2; Fri, 25 Mar 2016 21:19:02 + 0800 (CST)
From: root@app_server.localdomain (Cron Daemon)
To: root@app_server.localdomain
Subject: Cron <root @ app_server> bash/data/app_server/checkprocess. sh>/dev/null
Content-Type: text/plain; charset = UTF-8
Auto-Submitted: auto-generated
X-Cron-Env: <LANG = en_US.UTF-8>
X-Cron-Env: <SHELL =/bin/sh>
X-Cron-Env: <HOME =/root>
X-Cron-Env: <PATH =/usr/bin:/bin>
X-Cron-Env: <LOGNAME = root>
X-Cron-Env: <USER = root>
Message-Id: <20160325131902.78DB5403E2@app_server.localdomain>
Date: Fri, 25 Mar 2016 21:19:02 + 0800 (CST)
 
Start. sh: line 4:/sbin/sudo: No such file or directory # The sudo command cannot be found! My time ·~
The sudo execution in the script fails and the file cannot be found. It seems that simply loading the profile is not necessarily reliable!
③ Fix the script
Knowing the problem is easy to solve, and writing the absolute path/usr/bin/sudo of sudo directly.
Continue to test auto-pull. The result is still not good! R: G !!

III. Final Solution

Continue to view the system Email and find the following information:

Subject: Cron <root @ free-node-us> source/etc/profile; bash/data/app_server/checkprocess. sh>/dev/null
Content-Type: text/plain; charset = UTF-8
Auto-Submitted: auto-generated
X-Cron-Env: <LANG = en_US.UTF-8>
X-Cron-Env: <SHELL =/bin/sh>
X-Cron-Env: <HOME =/root>
X-Cron-Env: <PATH =/usr/bin:/bin>
X-Cron-Env: <LOGNAME = root>
X-Cron-Env: <USER = root>
Message-Id: <20160325132403.0E8E1403E2@app_server.localdomain>
Date: Fri, 25 Mar 2016 21:24:03 + 0800 (CST)
 
Sudo: sorry, you must have a tty to run sudo # it turns out to be a problem!
Obviously, it is prompted that sudo must be executed by tty. The solution is simple. Just remove this restriction!
Edit/etc/sudoers, find Defaults requiretty, and comment out this line:
 

Vim/etc/sudoers
 
# Defaults requiretty

Last use: x! Or: wq! Force save.
The same error was reported! After this sudo is changed, the running crontab is not affected. Therefore, restart the crontab service to refresh the settings:
 
Service crond restart

Now it's okay!

IV. Analysis Summary

In Linux, crontab is not executed as scheduled. This is a common fault in O & M. Based on experience, you can analyze and solve the problem as follows:

① Check whether the crontab service is normal
This is usually checked by viewing logs, that is, the/var/log/cron or/var/log/messages mentioned above. If no execution record is found, you can restart this service: service crond restart
② Check the execution permission of the script
In general, we recommend using sh or bash to execute shell scripts in crontab to avoid task failure due to the loss of execution permissions of script files. Of course, the most direct check is to manually copy the command line test results in crontab-l.
③ Check the variables required by the script
As mentioned above, the scripts executed in crontab are different from the environment variables manually executed. Therefore, for some system variables, we recommend that you write absolute paths or use witch to dynamically obtain them, for example, sudo_bin = $ (which sudo) can get the absolute path of sudo in the current system.
4. Zoom In: View Logs
In fact, the most direct and most effective way is to view the execution log. In combination with the crontab execution record and the system Mail after the crontab execution error, the cause of the failure is generally found completely! Of course, remember not to send emails if the error message is blocked in crontab.
This reminds me that if the crontab is not blocked, the hard disk inode may be full ==> history article portal, for more information, see/var/spool/clientmqueue.