I have solved the above problem by adding the statement "delete the lock file and create a new lock file" in the script. I found that crontab is triggered every time the lock file is new.
As can be seen from the picture, as long as the current time is detected and 499 appears, a script called nginxchen.sh will be triggered. The execution time of this script is about 8 minutes.
To be honest, I don’t know the specific reason for this. To borrow a sentence: practice is the only criterion for testing truth, so I simulated the original poster’s scenario
1. Write a script that takes more than 2 minutes and then execute it
2. Put it in crontab */1 * * * * flock -xn /root/xx.lock -c 'sh /root/xx.sh >>/tmp/xx.log 2>&1'
3. View crontab execution content
It can be found that there is no problem mentioned by the original poster
So here are the following suggestions: 1. Write a short script and test it on the server. If it doesn’t work, change the server to see if the situation is the same 2. Check the /mnt/499.log log for any abnormal output 3. Check whether the process has been running or is stuck, causing crontab to be unable to obtain the lock
That’s it. If the poster finds the reason himself, don’t forget to post it
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
I have solved the above problem by adding the statement "delete the lock file and create a new lock file" in the script. I found that crontab is triggered every time the lock file is new.
As can be seen from the picture, as long as the current time is detected and 499 appears, a script called nginxchen.sh will be triggered. The execution time of this script is about 8 minutes.
To be honest, I don’t know the specific reason for this. To borrow a sentence: practice is the only criterion for testing truth, so I simulated the original poster’s scenario
1. Write a script that takes more than 2 minutes and then execute it
2. Put it in crontab
*/1 * * * * flock -xn /root/xx.lock -c 'sh /root/xx.sh >>/tmp/xx.log 2>&1'
3. View crontab execution content
It can be found that there is no problem mentioned by the original poster
So here are the following suggestions:
1. Write a short script and test it on the server. If it doesn’t work, change the server to see if the situation is the same
2. Check the /mnt/499.log log for any abnormal output
3. Check whether the process has been running or is stuck, causing crontab to be unable to obtain the lock
That’s it. If the poster finds the reason himself, don’t forget to post it