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无法拿到锁
就以上这些了，如果楼主自己找到原因，不要忘记贴出来啊
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
我已经解决了上面的问题，那就是在脚本里添加“删除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无法拿到锁
就以上这些了，如果楼主自己找到原因，不要忘记贴出来啊