The pitfalls of using the flock command in crond

Pitfalls in crond using the flock command

You need to execute a PHP script on a regular basis. The first thought is to use the crond command to implement this function. However, a strange thing was found during the execution of crond. The configuration in crond is as follows.

*/1 * * * * root /usr/bin/flock -xn /tmp/test.lock -c '/usr/bin/php /home/hailong/test.php > /tmp/test.tt 2>&1'

The script will only be successfully executed for the first time and will not be executed again. After the/tmp/test. lock file is deleted, the PHP script runs properly again. After the execution is completed, the execution fails again.

Digress:

As you can see, the configuration file is added with 2> & 1. Why do we need to add 2> & 1? Please refer to the blog post "process crash caused by an echo"

In addition, careful friends will also find that we use the flock command. The flock command is used to prevent the script from being repeatedly executed concurrently. For more methods to control the concurrent execution of crond scripts, refer to "solve the crond script execution concurrency conflict problem".

Analysis

Remove flock from crond configuration. As follows:

*/1 * * * * root /usr/bin/php /home/hailong/test.php > /tmp/test.tt 2>&1

The script can be executed normally. It must be a flock problem. As a mature linux command, flock is unlikely to have problems. The biggest possibility is that some PHP code conflicts with flock. The PHP code is as follows:

Previously, it was said that only when the flock lock file does not exist for the first time can it be executed normally. When the lock file exists, it is no longer executed normally. After the PHP program is executed, flock does not release the file lock. We can see that the/tmp/test. lock file is occupied by that file.

[hailong@vhost ~]$ sudo /usr/sbin/lsof | grep test.lockexfilter  29821        root    3r      REG              202,1           0   90439710 /tmp/test.lock[hailong@vhost ~]$ ps aux | grep 29821root     29821  0.1  0.2 175224 22596 ?        Ssl  07:46   0:00 /home/exfilter -d56667    30068  0.0  0.0  69460   852 pts/0    S+   07:49   0:00 grep 29821

It can be seen that the test. lock file is occupied by the process started by the popen function in the PHP program. Because a daemon is started and the process does not exit, the lock is always occupied.

Solution

Enable the flock command and use other methods. For more methods, see the blog article "solving crond script execution concurrency conflicts".

Additional reading

In Linux, file locks are divided into advisory locks and mandatory locks ). Most of the file locks used in Linux are collaborative locks, and you must also check whether the system supports forced locks when using forced locks.

A collaborative lock is a file lock applied by a user process to take effect. For example, process A has added A collaborative lock to the file. if Process B does not apply for A lock, it is also possible to directly write the file.

The forced lock is guaranteed by the operating system kernel. The user process does not need to apply for it by itself.

The flock command uses a collaborative lock.

After a master process acquires a file lock, the child process that fork generates also obtains the file lock.

Link to the original article: The pitfalls of using the flock command in crond. For more information, see the source!