84669 人学习
152542 人学习
20005 人学习
5487 人学习
7821 人学习
359900 人学习
3350 人学习
180660 人学习
48569 人学习
18603 人学习
40936 人学习
1549 人学习
1183 人学习
32909 人学习
业精于勤，荒于嬉;行成于思，毁于随。
我已经解决了上面的问题，那就是在脚本里添加“删除lock文件，新建lock文件”的语句。我发现每次lock文件是新的时候才会触发crontab。
从图可见，只要检测是当前时间出现499 就会触发一个叫nginxchen.sh的脚本，这个脚本执行时间大约8分钟。
说实话，我也不知道你这个具体是什么原因，借用一句话：实践是检验真理的唯一标准，因此我模拟了楼主的场景
1.编写一个执行超过2分钟的脚本，然后执行
2.放到crontab*/1 * * * * flock -xn /root/xx.lock -c 'sh /root/xx.sh >>/tmp/xx.log 2>&1'
3.查看crontab执行内容
可以发现，并没有楼主所说的问题
因此有以下建议：1.编写一个简短的脚本在服务器上面测试，如果不行，就换台服务器，看看是否状况相同2.查看 /mnt/499.log 日志有无异常输出3.查看进程是否一直在运行或者卡死导致crontab无法拿到锁
就以上这些了，如果楼主自己找到原因，不要忘记贴出来啊
我已经解决了上面的问题，那就是在脚本里添加“删除lock文件，新建lock文件”的语句。我发现每次lock文件是新的时候才会触发crontab。
从图可见，只要检测是当前时间出现499 就会触发一个叫nginxchen.sh的脚本，这个脚本执行时间大约8分钟。
说实话，我也不知道你这个具体是什么原因，借用一句话：实践是检验真理的唯一标准，因此我模拟了楼主的场景
1.编写一个执行超过2分钟的脚本，然后执行
2.放到crontab
*/1 * * * * flock -xn /root/xx.lock -c 'sh /root/xx.sh >>/tmp/xx.log 2>&1'
3.查看crontab执行内容
可以发现，并没有楼主所说的问题
因此有以下建议：
1.编写一个简短的脚本在服务器上面测试，如果不行，就换台服务器，看看是否状况相同
2.查看 /mnt/499.log 日志有无异常输出
3.查看进程是否一直在运行或者卡死导致crontab无法拿到锁
就以上这些了，如果楼主自己找到原因，不要忘记贴出来啊