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

Editor to share with you how to solve the problem that crontab refreshes many times in a second, which leads to the ineffectiveness of some scripts. I believe most people don't know much about it, so share this article for your reference. I hope you can learn a lot after reading this article. Let's learn about it together.

Ob found monitoring tasks in crontab on several DB, which were never performed. However, by operating the configuration of crontab crontab-e + wq, the monitoring task can be executed normally, and the restart cron can also be executed normally.

The situation of the faulty machine crontab is as follows:

The problem is strange. The first crontab executes normally, while the second crontab never executes.

The first item is normal, which proves that cron is running normally. The crontab of the DB monitoring task is automatically installed by the Kelly system, and in theory there will be no sudden errors.

Problem location:

Is cron out of bug? It is true that the second task did not be executed, or quit due to problems before execution, and the log was printed to / dev/null again.

Considering that the crontab execution history will be recorded in the system log, check the var/log/message log as follows, and the whole * / 5 minute point is only the first task of crontab.

It is true that the second task of crontab did not be carried out. There should be something wrong with crontab, and see what happened at the moment of modifying crontab?

Based on the time when crontab was last modified (2012-06-18 17:51:01), check the system log as follows:

Coincidentally, the crontab was modified twice in the same second. According to the order in which Kelly installs the monitoring, the first crontab should be the installation of the first crontab task, and the second crontab should be the installation of the second crontab task.

Guess: according to how cron works, after adding the first task, cron loads the configuration of crontab (/ var/spool/cron/tabs/mysql), but after adding the second task, cron doesn't load the configuration? If so, what is the mechanism for cron to determine whether a configuration file needs to be loaded?

Online documents are scarce, look directly at the code.

Find a cron source code of debian on the Internet: cron_3.0pl1.orig.tar.gz

Unpack and open it to view the execution process of cron:

In the main function of cron.c, the main function code of cron is as follows:

Cron_sleep (): the minimum execution unit of crontab is minutes, so it is executed every 60 seconds. TargetTime + = 60

Load_database (): check whether the configuration file of crontab is updated, and if so, re-load, otherwise use the last recorded database cron_tick (): actually perform the task to see how cron loads the configuration file of crontab, enter the load_database () function.

Database.c:

As you can see, when cron loads the configuration, it will first obtain the stat information of the / var/spool/cron/tabs directory, and then obtain the stat information of the user's crontab configuration file, and then compare the last modification time with the tabs directory and the last modification time of the crontab configuration file. If the same, do not re-load, otherwise re-load crontab configuration file.

Stat is a system function call that gets the st_mtime of the structure in seconds.

So far, we can draw the following conclusion:

Because the two crontab modifications are in the same second, the loading of cron is based on the last modification time (seconds) of the crontab configuration file to determine whether the file needs to be updated. When the following scenario occurs, the second change to crontab becomes invalid (not just increased).

Scenarios in which crontab fails:

And this scenario happens to be the case of crontab failure in our DB.

The refresh mechanism of crontab is based on the last modification time of the crontab file.

Therefore, if you perform multiple operations on the crontab in one second (more than 1), it is possible that the modified crontab will not be executed!

When you save the crontab file again, cron reloads the configuration file and crontab takes effect.

Solution:

The problem is caused by performing multiple crontab changes in one second. So there are three solutions:

Add the operation of sleep 1 every time Kelly operates crontab

After Kelly completes each crontab operation, sleep 1 forcefully refreshes the last update time of the crontab

Merge parallel crontab operations into one operation, reducing the frequency of operations on crontab

According to Kelly's case, choose the second option to make minimal changes to the existing code.

Reminder:

The script should try not to manipulate the crontab content multiple times in the same second, otherwise the crontab may not take effect.

The above is all the contents of this article entitled "how to solve the problem that crontab refreshes many times in one second and causes some scripts not to work". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

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.