Summary of some reasons why the crontab timed task does not perform

preface

Recently, I met some problems in my work. crontab timing task was not executed. Later, When I searched online, I found the following five reasons:

crond service not started

crontab is not a function of the Linux kernel, but relies on an crond service that can be started or stopped. If you stop, you cannot perform any timed tasks. The solution is to turn it on:

crond

or

service crond start

If you are prompted that the crond command does not exist, it may have been deleted by mistake. You can reinstall CentOS using this command:

yum -y install crontabs

2. Permission Issues

For example: the script does not have x execution permission, the solution:

Increase execution permissions, or use the method bash abc.sh

It is also possible that the user to which the crontab task belongs does not have write permission to a directory and will fail

3 Path Problem

There are commands that execute normally in shell but always fail in crontab. It is possible that sh used by crontab did not correctly identify the path, for example: after logging on to shell as root, one /root/ test.sh is executed as long as it is executed

./test.sh

Just fine. But in crontab, you won't find this script, such as write the complete:

/root/test.sh

4 Time difference problem

Due to the time difference between the server and the client, the time of crontab is subject to the server time.

Jet lag is a real problem, and I've experienced it firsthand. Here's what it looks like:

(1) I set a timing script and observed the server's time with date command. When the script was executed, I found that it was not executed

(2) But I set the script to run once per minute, which is OK's

Damn it, server time is right, right? What time zone should I add? So I subtracted 10 or 12 or 8 hours from the script and I tried it and it didn't work.

But it is obvious that the time is not 1 caused by the non-execution.

Finally, the problem was solved with the following two lines:

cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime
service crond restart

Reference: this article https: / / www ofstack. com article / 154296. htm

5 Variable problems

Sometimes commands that contain variables that are not present when crontab is executed also cause execution to fail.

After verification, my timing script ES87en. sh is not executed for any of the above reasons, in fact, my script is only 1 sentence:

#!/bin/bash
echo 123 >> testFile

This way I wanted to test that the timing script I had set worked, so I set it to run once a minute, but I couldn't see the file in the directory where the script was living, so I executed it manually

# sh test.sh

You can see this file in the directory where the script is located

I suspect that crontab was not implemented at all, so I added it directly to crontab

*/1 * * * * echo 123 >> /home/denglinjie/testFile

The testFile file was generated, indicating that crontab was executed, which seems to be a problem with my script itself

It turned out that testFile had to write the full path here. I naively thought that testFile would be generated in the directory where the script is located, so I changed it to the following form

#!/bin/bash
echo 123 >> /data/denglinjie/testFile

And then you're done.

The path is a very easy problem. Suppose you have a script file in the /home/denglinjie directory, es115EN1.sh, and then another script file in that directory, ES117en2.sh

test2.sh is executed in test1.sh, and with a relative path, which is the path of es125EN1.sh.

If you are editing in ES129en-ES130en, the way to do this is

sh/home/denglinjie/test1 sh, when performing to the calling sh test2. sh, the system will think from crontab file directory to find test2. sh, but in fact is found, resulting in failure

The initial method I thought was that I would put the script file I wrote to be executed and the other scripts that were called and the crontab file in one place, so I could pull it, but it failed, because I could not get into the /var/spool/cron directory due to the permission problem.

So another solution is to go to the script directory via the cd /home/denglinjie command before executing the script

------------------------------------------------------------------

A new reason for crontab not to be implemented has recently been identified

Here I am going to execute the python script. The directory of my python script is:

service crond start

0

1 At the beginning, my timing task was written as follows:

service crond start

1

It was found that the time point was not executed, where the es171EN_ES172en.py part is as follows:

service crond start

2

It was my script that introduced my own pymongo, noting that this pymongo was installed on the specified VERSION of python

Reason for non-execution: When the crontab timed task was executed, the python I used was not my python. The python I used did not install pymongo, which led to the failure of import

The solution is to change it to the following form:

0 * * * * cd /data/denglinjie/work/UpdateModuleSwitch;/data/zhoumi/install_evn/bin/python update_switch.py

Specify python to run with, which python has been installed and bound to pymongo, or in the following form:

service crond start

4

Since my python is installed in my own user directory, the system cannot find this python, so I just need to add my python to the system PATH environment variable

conclusion