朋友弄了一个小项目，要我帮忙做下 Linux 系统运维，上线一段时间后，发现项目偶尔会挂掉导致服务不可用。开发朋友一时之间也没空去研究项目奔溃的根因，只好由我这个运维先写一个项目进程自拉起脚本，通过 Linux 任务计划每分钟检查一下进程是否存在来避免项目挂了没人管的情况。
自拉起脚本很简单，随便写几行就搞定了：
Shell
#!/bin/bash
processcount=$(pgrep my_app|wc-l)
cd$(cd$(dirname$0)&&pwd)
if[[0-eq$processcount]]
then
echo"[ $(date) ] : my_app is down, start it!"|tee-ai./checkprocess.log
bash./start.sh#这里是项目的重启脚本
else
echomy_app isOK!
fi然后丢到 crontab，1 分钟执行一次：
Shell
*****bash/data/app_server/checkprocess.sh>/dev/null2>&1本以为万事大吉了，结果还是坑了，进程再一次挂了，尼玛什么鬼？
一、检查日志
根据经验，先看一下 crontab 的日志：
tail /var/log/messages
没发现相关日志，看来不是打印到了这，于是查看了下 crontab 的默认日志位置：
tail /var/log/cron
Shell
Mar2521:40:01li733-135CROND[1959]:(root)CMD(sh/data/app_server/checkprocess.sh>/dev/null2>&1)
Mar2521:40:01li733-135CROND[1960]:(root)CMD(/usr/lib64/sa/sa111)
Mar2521:40:01li733-135CROND[1961]:(root)CMD(/usr/sbin/ntpdate pool.ntp.org>/dev/null2>&1)
Mar2521:41:01li733-135CROND[2066]:(root)CMD(sh/data/app_server/checkprocess.sh>/dev/null2>&1)很明显，任务计划确实在正常执行着，看来问题在脚本上了。
二、检查脚本
①、直接执行
检查脚本第一步，直接按照 crontab 里面的命令行，执行脚本：
Shell
sh/data/app_server/checkprocess.sh
[Fri Mar2521:25:01CST2016]:my_app isdown,start it!
sh/data/app_server/checkprocess.sh
my_app isOK!结果进程正常拉起了！
直接执行成功，而放到 crontab 就失败，经验告诉我肯定的脚本环境变量有问题了！
②、环境变量
于是在脚本里面载入环境变量：
Shell
#!/bin/bash
#先载入环境变量
source/etc/profile
#其他代码不变然后手工把进程杀死，等待自拉起，结果... 还是不行！
③、系统邮件
经验告诉我，crontab 执行失败，如果没有屏蔽错误的话，会产生一个系统邮件，
位置在 /var/spool/mail/root
所以，我把 crontab 里面的 2>&1 这个屏蔽错误先取消掉，等待几分钟查看邮件。
cat /var/spool/mail/root 发现有如下报错：
From root@free-node-us.localdomain Fri Mar2521:30:022016
Return-Path:<root@app_server.localdomain>
X-Original-To:root
Delivered-To:root@app_server.localdomain
Received:by app_server.localdomain(Postfix,from userid0)
id78DB5403E2;Fri,25Mar201621:19:02+0800(CST)
From:root@app_server.localdomain(Cron Daemon)
To:root@app_server.localdomain
Subject:Cron<root@app_server>bash/data/app_server/checkprocess.sh>/dev/null
Content-Type:text/plain;charset=UTF-8
Auto-Submitted:auto-generated
X-Cron-Env:<LANG=en_US.UTF-8>
X-Cron-Env:<SHELL=/bin/sh>
X-Cron-Env:<HOME=/root>
X-Cron-Env:<PATH=/usr/bin:/bin>
X-Cron-Env:<LOGNAME=root>
X-Cron-Env:<USER=root>
Message-Id:<20160325131902.78DB5403E2@app_server.localdomain>
Date:Fri,25Mar201621:19:02+0800(CST)
start.sh:line4:/sbin/sudo:No such file ordirectory#sudo命令找不到！我次奥·~居然是脚本里面的 sudo 执行失败了，找不到这个文件。看来单纯的载入 profile 不一定靠谱啊！
③、修复脚本
知道问题所在，解决就简单了，粗暴点，直接写入 sudo 的绝对路径 /usr/bin/sudo
继续测试自拉起，结果... 还是不行！R 了 G 了！！
三、最终解决
继续查看了下系统邮件，发现如下信息：
Subject:Cron<root@free-node-us>source/etc/profile;bash/data/app_server/checkprocess.sh>/dev/null
Content-Type:text/plain;charset=UTF-8
Auto-Submitted:auto-generated
X-Cron-Env:<LANG=en_US.UTF-8>
X-Cron-Env:<SHELL=/bin/sh>
X-Cron-Env:<HOME=/root>
X-Cron-Env:<PATH=/usr/bin:/bin>
X-Cron-Env:<LOGNAME=root>
X-Cron-Env:<USER=root>
Message-Id:<20160325132403.0E8E1403E2@app_server.localdomain>
Date:Fri,25Mar201621:24:03+0800(CST)
sudo:sorry,you must haveatty torun sudo#原来是这个问题！很明显，提示了 sudo 必须需要 tty 才能执行，解决很简单，取消这个限制即可！
编辑 /etc/sudoers ，找到 Defaults requiretty, 然后注释掉这行：
vim/etc/sudoers
#Defaults requiretty最后使用 :x! 或 :wq! 强制保存即可。
结果观察还是报了相同的错误！原来改完这个 sudo 并不会影响已经运行的 crontab，所以需要重启 crontab 服务刷新下设置：
service crond restart这下终于可以了！
四、分析总结
Linux 系统里面计划任务，crontab 没有如期执行这是运维工作中比较常见的一种故障了，根据经验，大家可以从如下角度分析解决:
①、检查 crontab 服务是否正常
这个一般通过查看日志来检查，也就是前文提到的 /var/log/cron 或 /var/log/messages，如果里面没有发现执行记录，那么可以重启下这个服务：service crond restart
②、检查脚本的执行权限
一般来说，在 crontab 中建议使用 sh 或 bash 来执行 shell 脚本，避免因脚本文件的执行权限丢失导致任务失败。当然，最直接检查就是人工直接复制 crontab -l 里面的命令行测试结果。
③、检查脚本需要用到的变量
和上文一样，通常来说从 crontab 里面执行的脚本和人工执行的环境变量是不一样的，所以对于一些系统变量，建议写绝对路径，或使用 witch 动态获取，比如 sudo_bin=$(which sudo) 就能拿到 sudo 在当前系统的绝对路径了。
④、放大招：查看日志
其实，最直接最有效的就是查看执行日志了，结合 crontab 执行记录，以及 crontab 执行出错后的系统邮件，一般都能彻底找到失败的原因了！当然，要记住在 crontab 中如果屏蔽了错误信息，就不会发邮件了。
这又让我想起了如果 crontab 未屏蔽日志，可能会导致硬盘 inode 爆满 ==> 历史文章传送门 ，感兴趣的童鞋也可以谷歌一下 /var/spool/clientmqueue/ 这个关键词了解下。
好了，本文分享到此，希望对你有所帮助！
Centos7已经写了要chmod +x /etc/rc.d/rc.local 授权一下才会起作用
当然有的时候也可能不成功，比如：
/etc/rc.d/rc.local 文件中的内容格式不正确：
开头少了#!/bin/bash，也是执行不成功的，会提示你格式不对。
也可能由于是环境变量的问题
可直接在/etc/rc.local文件中加入：source /etc/profile
或者 通过 su -c 自动带入环境变量
此外还可能是没有启动此项服务：
#systemctl list-units --type=service #来查看一下所有的开启启动项目里面有没有这个rc-local这个服务。
#systemctl status rc-local.service #来查看一下当前是怎么个状态
然后：
#systemctl enable rc-local.service
#systemctl start rc-local.service
#手工添加下开机启动或者手工起一下看报错信息。
另外：服务的启动文件是存放在了：/lib/systemd/system/目录下面，如果不记得这个服务的全称可以来这个目录下面看。
