Simple protection against double cron jobs
I want to talk about a simple script that allows you to protect yourself from a double launch of cron jobs.
Let's say that once a minute you update a certain cache in order to quickly give it to millions of site visitors. Everything is going fine, but exactly until a weekly backup is launched late at night and your cache is not formed in 10 seconds, but in 70, and in 60 seconds it will be followed by another cache formation process.
What will happen next in such a scenario is a very interesting question. It is likely that the two processes will actively interfere with each other (they work with the same objects), and their total execution time will not be twice as long as usual, and if the third one will overtake ...
The described situation is trivial to obscenity, although a degenerate variant is more common: there is no crown, justat midnight at the time of expiration of the cache, each new visitor starts a fat process and the server turns into a pumpkin .
As a developer, you must provide such a scenario and protect yourself from it. But ifPinocchio was stupid , your software developers didn’t care about it, you’ll have to save yourself.
')
I use a simple and convenient lockrun utility. The principle of its operation is simple: for each process, it creates a file and locks it onto it. As soon as the process is complete, the lock disappears. Lock also disappears in case of sudden death of the process, and there is no need to check the pid for existence or to make other gestures. If the process is restarted, and the lock file has not yet been released, the script is interrupted and a message is displayed in STDERR.
The utility is written in C, so you have to compile it on the target machine before using it. So, we swing, we compile and we put where it is necessary:
If you are not root, you will have to ignore the last line and either specify the full path or change the PATH.
Example of use:
The command and parameters of lockrun are divided by two minuses.
The following parameters are accepted:
--lockfile = / path / to / file
Required parameter that specifies the file name for the loc. If there is no such file, it will be created automatically. Of course, for each job must be its own file.
--maxtime = N
The time in seconds that the script takes to “normal” work. If the script worked longer, a message will appear in STDERR, which cron can send you by mail.
--wait
If this parameter is specified, lockrun will not cancel the script execution, but will wait until the previous process releases the lock.
--verbose
As always, issuing more detailed information on the process.
--quiet
Do not issue error messages. It can be enabled if refusing to start a job is not a serious problem.
That's all. As you can see, really simple and effective.
UPD: In the comments I was informed that there is also a native tool for Linux.
Of course, no one claimed that the described utility is the only solution.
Let's say that once a minute you update a certain cache in order to quickly give it to millions of site visitors. Everything is going fine, but exactly until a weekly backup is launched late at night and your cache is not formed in 10 seconds, but in 70, and in 60 seconds it will be followed by another cache formation process.
What will happen next in such a scenario is a very interesting question. It is likely that the two processes will actively interfere with each other (they work with the same objects), and their total execution time will not be twice as long as usual, and if the third one will overtake ...
The described situation is trivial to obscenity, although a degenerate variant is more common: there is no crown, just
As a developer, you must provide such a scenario and protect yourself from it. But if
')
I use a simple and convenient lockrun utility. The principle of its operation is simple: for each process, it creates a file and locks it onto it. As soon as the process is complete, the lock disappears. Lock also disappears in case of sudden death of the process, and there is no need to check the pid for existence or to make other gestures. If the process is restarted, and the lock file has not yet been released, the script is interrupted and a message is displayed in STDERR.
The utility is written in C, so you have to compile it on the target machine before using it. So, we swing, we compile and we put where it is necessary:
$ wget unixwiz.net/tools/lockrun.c
$ gcc lockrun.c -o lockrun
$ sudo cp lockrun /usr/local/bin/If you are not root, you will have to ignore the last line and either specify the full path or change the PATH.
Example of use:
* * * * * /usr/local/bin/lockrun --lockfile=/tmp/megacache.lockrun -- /path/to/megacache/generatorThe command and parameters of lockrun are divided by two minuses.
The following parameters are accepted:
--lockfile = / path / to / file
Required parameter that specifies the file name for the loc. If there is no such file, it will be created automatically. Of course, for each job must be its own file.
--maxtime = N
The time in seconds that the script takes to “normal” work. If the script worked longer, a message will appear in STDERR, which cron can send you by mail.
--wait
If this parameter is specified, lockrun will not cancel the script execution, but will wait until the previous process releases the lock.
--verbose
As always, issuing more detailed information on the process.
--quiet
Do not issue error messages. It can be enabled if refusing to start a job is not a serious problem.
That's all. As you can see, really simple and effective.
UPD: In the comments I was informed that there is also a native tool for Linux.
Of course, no one claimed that the described utility is the only solution.
Source: https://habr.com/ru/post/114622/
All Articles