记一次LINUX-CRONTAB失败的排查案例

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了记一次LINUX-CRONTAB失败的排查案例相关的知识,希望对你有一定的参考价值。

在LINUX中,使用crontab来做计划任务是一件很常见的事。本文记录一次排查过程

故障描述

在crontab 设置计划任务,每天凌晨3点执行脚本

conrtab(3点)tomcat用户--执行脚本(推送备文件-->目标服务器||同时将过程写入LOG记录)

然而在第二天例常检查后,发现计划任务没有达到预期效果

排查步骤

首先检查计划任务是否执行

/var/log/cron如下:

Jan 30 03:00:01 z00w00-host CROND[2375]: (tomcat) CMD (/usr/bin/run-parts /usr/share/tomcat/tomcat_backup)
Jan 30 03:00:01 z00w00-host run-parts(/usr/share/tomcat/tomcat_backup)[2375]: starting autosyrc.sh
Jan 30 03:00:01 z00w00-host run-parts(/usr/share/tomcat/tomcat_backup)[2395]: finished autosyrc.sh

主机名我进行了加工,其他基本保持不变

通过日志可以看出在凌晨3点的时候计划任务确实忠实的开始了,但是仅仅1秒钟就结束了任务,这显然是不正常的,因为是推送文件,按照经验判断,至少需要一段时间。

Feb  1 03:00:01 z00w00-host CROND[20514]: (tomcat) CMD (/usr/bin/run-parts /usr/share/tomcat/tomcat_backup)
Feb  1 03:00:01 z00w00-host run-parts(/usr/share/tomcat/tomcat_backup)[20514]: starting autosyrc.sh
Feb  1 03:04:02 z00w00-host run-parts(/usr/share/tomcat/tomcat_backup)[20615]: finished autosyrc.sh

以上是我解决问题后在今天抓取的日志,可以看到正常脚本执行推送文件应该是在4分钟左右。

是脚本逻辑问题吗?

实际上脚本编写完成后,我就在交互式终端中执行了一下,是正常运行的。 另外又检查了一下脚本,这个脚本是在我原来的脚本基础上改的,只是修改了一些变量,逻辑本身没有什么太大问题。

是执行权限的问题

还记得我开头说的吗?脚本进行推送文件,同时将过程写入日志。问题就出在这里

原来,我修改脚本后,为了当时验证效果,将原日志文件rsync.log 进行了重命名 在人工执行的时候rsync.log 被重建了。由于我是root用户执行,所以rsync.log的属主变成了root,而计划任务中,我的执行用户是tomcat。由于文件属主发生变化,tomcat无法写入root属主的rsync.log,导致脚本在计划任务中秒执行但实际上没有按预期来达到目标。
排查中也发现日志文件时间没有任何变化。

解决的办法

分析后查看文件属主,果然如此。修改属主后,修改计划任务,验证执行,故障解除。

修改前的属主

-rwxr-xr-x 1 tomcat tomcat 1.5K Jan 29 14:55 autosyrc.sh
-rw-r--r-- 1 root root 164K Jan  31 14:55 rsync.log

修改后的属主

-rwxr-xr-x 1 tomcat tomcat 1.5K Jan 29 14:55 autosyrc.sh
-rw-r--r-- 1 tomcat tomcat 164K Feb  1 03:04 rsync.log

问题解决,打完收工

以上是关于记一次LINUX-CRONTAB失败的排查案例的主要内容,如果未能解决你的问题,请参考以下文章

记一次chrony同步失败问题排查

解Bug之路-记一次调用外网服务概率性失败问题的排查

JVM记一次PermGen space内存溢出实战案例

云原生(18):记一次上云原生失败的案例

记一次Elasticsearch GeoIpDownloader的启动异常排查过程

破案现场:记一次压测异常排查--Redisson锁失效的场景