小编给大家分享一下如何解决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在一秒内刷新多次导致部分脚本不生效的问题”这篇文章的所有内容,感谢各位的阅读!相信大家都有了一定的了解,希望分享的内容对大家有所帮助,如果还想学习更多知识,欢迎关注亿速云行业资讯频道!
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。