Shulou(Shulou.com)06/02 Report--

Preface

Recently, I encountered some problems at work. I actually didn't perform crontab scheduled tasks. Later, when I was looking for it on the Internet, I found that there were five main reasons on the Internet:

1 the crond service is not started

Crontab is not a function of the Linux kernel, but relies on a crond service that can be started or stopped. If you stop, you will not be able to perform any scheduled tasks, the solution is to open it:

Crond

Or

Service crond start

If you prompt that the crond command does not exist, it may have been deleted by mistake, and you can reinstall it under CentOS with this command:

Yum-y install crontabs

2 permission issues

For example, if the script does not have the permission to execute x, the solution:

Increase the execution permission, or use the bash abc.sh method to execute

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

3 path problem

Some commands execute normally in shell, but always fail in crontab. It may be because the sh used by crontab does not correctly identify the path, for example, execute a / root/test.sh after logging in to shell as root, as long as you execute

. / test.sh

Just do it. But in crontab, you can't find this script, such as writing a complete script:

/ root/test.sh

4 problem of jet lag

Because of the time difference between the server and the client, the time of the crontab depends on the server time.

The problem of jet lag is really funny. I have experienced it myself, and the phenomenon is as follows:

(1) I set up a timed script and used the date command to observe the time of the server. When the time of execution of the script reached, I found that it was not executed.

(2) but I set the script to be executed every minute, which is OK's

Hell, is the server time right? Do you want to add a time zone? So I tried to reduce the script time by 10 or 12 or 8 hours, and found that it didn't work.

But it is obvious that the non-execution is caused by the inconsistency of time.

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

Cp / usr/share/zoneinfo/Asia/Shanghai / etc/localtimeservice crond restart

Refer to this article: https://www.jb51.net/article/154296.htm

5 variable problem

Sometimes the command contains variables, but crontab does not have them, which can also cause execution to fail.

After verification, it is not for any of the above reasons that my timed script test.sh does not execute. In fact, my script has only one sentence:

#! / bin/bashecho 123 > > testFile

I wanted to test that the timing script I set worked in this way, so I set the script to be executed every minute, but I couldn't see the file in the directory where the script was located, so I executed it manually.

# sh test.sh

But you can see this file in the directory where the script is located.

I suspected that crontab was not executed at all, so I added it directly to crontab

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

The testFile file is generated, which means that crontab is executed. It seems that there is a problem with my script itself.

#! / bin/bashecho 123 > > / data/denglinjie/testFile

And then it's okay.

In fact, the path is a very easy place to go wrong, suppose there is a script file test1.sh in the / home/denglinjie directory, and then there is a script file test2.sh in that directory

Test2.sh is executed in test1.sh, and the relative path is used, that is, the path where the relative test1.sh is located.

If you edit it in crontab-e, it will be executed as follows

Sh / home/denglinjie/test1.sh, when executing to call sh test2.sh, the system will think that it is to find test2.sh from the directory where the crontab file is located, but it cannot be found, causing the execution to fail.

At first, I wanted to put the script files I wrote to execute and other scripts and crontab files that were called in one place, so that I could pull them, but failed, probably because of permission problems, I couldn't get into the / var/spool/cron directory.

So another solution is to enter the directory where the script is located by using the cd / home/denglinjie command before executing the script

-

Recently, a new reason for the non-execution of crontab has been discovered.

What I'm going to execute here is the python script, and the directory of my python script is:

/ data/denglinjie/work/UpdateModuleSwitch

At first, my scheduled task was written like this:

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

It is found that it has not been executed at the point in time. Some of the contents of update_switch.py are as follows:

Import pymongo

It is my script that introduces the self-installed pymongo. Note that this pymongo is installed on the specified version of python.

Reason for not executing: when crontab scheduled task execution, the python used was not my python, and the python used did not install pymongo, resulting in import failure

The solution should be changed to the following form:

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

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

0 * export PATH=/data/zhoumi/install_evn/bin/:$PATH;cd / data/denglinjie/work/UpdateModuleSwitch;python update_switch.py

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

Summary

The above is the whole content of this article, I hope that the content of this article has a certain reference and learning value for your study or work, if you have any questions, you can leave a message and exchange, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.