L018-crond的生产场景经验小节

L018-crond的生产场景经验小节

怎么说呢，其实L018这节课还是巩固crond的知识，前半堂课主要是解决上堂课老师留的作业（在L017已经更新，拉到最后），然后剩下的半堂客主要是讲解了一些生产场景实例，不过大多数还是总结要点，所以这篇主要还是把关于crond定时任务所有的内容做一个总结贴出来，以后使用crontab时可以参考，下面开始：

 

企业生产场景如何调试crontab定时任务

一、增加执行任务频率调试任务（某些任务不能用于生产环境）

在调试时，把任务执行频率调调快一点，如：每分钟、每5分钟执行一次，或者笔当前时间退出5分钟以后，看能否执行，是不是按照你的想象去执行了，如果整整没问题，再改成需要的任务的执行时间。
注意：有些计划任务不允许频繁执行的，例如：定时往数据库里插数据，这样的任务就要在测试机上测试好，然后部署到正式线上，这样正式工作的问题的寄回就少了。
规范的操作流程：个人的开发配置环境-->办公室的测试环境-->idc机房的测试环境-->idc机房的正式环境

使用log文件调试任务，把/dev/null 2>&1换成某一对象定向，这样通过看文件就可知道定时任务是否执行，是正确还是错误。

 

二、调整系统时间调试任务（不能用于生产环境）

用正确的执行任务的时间，设置完成后，可以修改当前时间，改成任务执行时间的前几分钟来测试（或者重启定时任务服务）。如：定时任务9：00执行，我们可以把系统时间改成8：55分，然后观察是不是正确执行了，当前时间比任务时间要提前足够长，如果是生产环境服务器不可以这样处理，测试环境可以使用这个手段。
例如：周三的2：00执行。
把系统时间调整为周三凌晨1：55分（至少5分钟）

 

三、通过脚本日志输出调试定时任务

在脚本中加入日志输出，然后把输出打到指定的日志中，然后观察日志内容结果，看是否执行或正确执行。或像下面的内容把脚本结果定向到一个log文件里，重定向“>”即可。不需要“>>”追加，这样日志就不会一直变大，如/app/log.log。也可以在脚本里面打日志。

这个就是我在第一方面里后面说的话。

 

四、注意一些任务命令带来的问题

注意：*/1 * * * * echo "==" >> /tmp/oldboy.log >/dev/null 2>&1这是隐蔽的无法正确执行的任务配置，原因是前面多了">>",或者去掉结尾的>/dev/null 2>&1。

强调：此问题时因为前面已经有重定向，后面要去掉>/dev/null 2>&1

 

五、注意环境变量导致的定时任务故障

在调试java程序任务的时候，注意环境变量，把环境变量的定义加到脚本里。

 

六、通过crond定时任务服务日志调试定时任务

查看定时任务服务日志

[root@moban ~]# tail -f /var/log/cron

由此来找到出问题的时间点，给解决问题带来抓手

 

七、其他稀奇古怪的问题调试方法

结合前面1-6的方法就可以解决几乎所有遇到的问题，此类问题主要是多看crond服务日志，并且把程序输出到指定日志分析。

 

关于编写定时任务的方法要领总结：

要领1：为定时任务规则加必要的注释
要领2：执行shell脚本任务前加/bin/sh
要领3：定时任务命令或脚本的结尾加>/dev/null 2>&1
要领4：定时任务命令或程序最好写到脚本里执行
要领5：在指定用户下执行相关定时任务
要领6：在生产任务程序不要随意打印输出信息 tar zcf echo 123 >a.log
要领7：定时任务执行的脚本要规范路径
要领8：配置定时任务规范操作过程

 

生产应用问题10箴言

1.系统环境变量问题
2.定时任务要用绝对路径
3.脚本权限问题加/bin/sh
4.时间变量问题要用反斜线 如“%”
5.>/dev/null 2>&1问题 （1>/dev/null 2>/dev/null）防止占满inode
6.定时任务规则之前加注释
7.使用脚本替代命令定时任务
8.避免不必要的程序及命令输出
9.切到目标目录的上一级打包目标
10.定时任务脚本中的程序命令用全路径

 

还有一个小问题

当文件太多，使用rm -fr *.* 无法删除的时候，我们可以使用下面的命令

1.ls | xargs rm -f

2.find ./ -typr -f | xargs rm -f

3.删除原文件夹，但是前提记住原目录属性，重新建立后恢复（但是一定要小心谨慎）

 

最后，学linux也已经有一阵子了，发现前面的也快忘差不多了，下周一周的时间我会统一复习一下之前的课程内容作为巩固，可能会更新一篇心得吧。