小编给大家分享一下如何解决crontab在一秒内刷新多次导致部分脚本不生效的问题，相信大部分人都还不怎么了解，因此分享这篇文章给大家参考一下，希望大家阅读完这篇文章后大有收获，下面让我们一起去了解一下吧！
ob在几台DB上发现crontab中的监控任务,从来没有执行。但操作一下crontab的配置crontab –e + wq,监控任务就能正常执行，重启cron也能正常执行。
出问题的机器crontab的情况如下：
问题挺奇怪，第一条crontab执行正常,第二条crontab一直没有执行。
第一条正常,证明cron有正常运行。DB监控任务的crontab是凯丽系统自动安装的，理论上不会存在突然出错的情况。
问题定位：
cron出bug了? 第二个任务确实没有执行,还是执行前遇到问题退出,刚好日志又打印到/dev/null了..
考虑到crontab执行历史在系统日志里会有记录，检查var/log/message日志如下，整*/5的分钟点只有crontab的第一个任务。
crontab第二个任务确实没执行，应该是crontab出了点问题,再看看在修改crontab的那一刻发生了什么？
根据crontab最后一次修改的时间(2012-06-18 17:51:01),检查系统日志如下:
刚巧,在同一秒内修改了2次crontab。根据凯丽安装监控的顺序，第一个crontab应该是在安装第一条crontab任务，第二个crontab应该是在安装第二个crontab任务。
猜想：根据cron的工作原理,难道在增加第一个任务之后，cron加载了crontab的配置（/var/spool/cron/tabs/mysql），但是在增加第二个任务之后，cron没有加载该配置? 如果是这样,那么cron判断是否需要加载配置文件的机制是如何的呢?
网上文档稀少,直接看代码。
在网上找到一个debian的cron源代码: cron_3.0pl1.orig.tar.gz
解压打开,查看cron的执行过程:
在cron.c 的main函数中,cron的主函数代码如下:
cron_sleep(): crontab 最小执行单位是分钟,因此是每60秒执行一次.TargetTime += 60;
load_database(): 检查crontab的配置文件是否有更新,如果有更新,则重新load,否则使用上次记录的database cron_tick( ): 实际执行任务查看cron是如何加载crontab的配置文件的，进入load_database()函数.
database.c :
可以看到,在cron加载配置的时候,会先获取/var/spool/cron/tabs 目录stat信息,然后获取用户的crontab配置文件的stat信息，然后比较上一次统计的修改时间与tabs目录、crontab配置文件的最后修改时间，如果一致则不重新load，否则重新load crontab配置文件。
stat为系统函数调用,该函数取得的结构体的st_mtime的单位为秒。
至此，我们可以得出这样的结论：
由于两次crontab修改时间均在同一秒，而cron的加载是以crontab配置文件的最后修改时间（秒级）来判断文件是否需要更新。当出现以下场景，第二次对crontab的修改就会失效（不仅是增加）。
crontab失效的场景：
而这个场景,刚好是我们的DB出现crontab失效的情况。
crontab的刷新机制,是以crontab文件的最后修改时间为准.
因此,如果在一秒内对crontab进行多次(大于1次)操作,就可能出现后修改的crontab不执行!
当再次对crontab文件进行保存操作时,cron会重新加载配置文件,crontab生效.
解决办法：
该问题是由于在一秒内执行多次crontab变更导致。因此解决办法有3个：
在凯丽每次操作crontab的时候增加sleep 1的操作
在凯丽每次crontab操作完成之后，sleep 1,强制刷新crontab的最后更新时间
合并并行的crontab操作为一次操作,减少对crontab的操作频率
根据凯丽的情况,选择第二个方案对现有代码改动最小。
提醒：
脚本尽量不要在同一秒内多次操作crontab内容，否则可能导致crontab不生效的情况。
以上是“如何解决crontab在一秒内刷新多次导致部分脚本不生效的问题”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注天达云行业资讯频道！