Redian新闻
>
Linux计划任务crontab运行脚本不正确的问题

Linux计划任务crontab运行脚本不正确的问题

公众号新闻

阅读目录

  • 问题的由来

  • 问题描述

  • 问题分析

  • 问题解决

问题的由来

写好的程序希望在崩溃之后能够自启动,于是利用linux的crontab功能,添加一个计划任务,每分钟执行一个脚本查看需要监控的进程是否还在,如果不在则启动之,否则不做任何事情。这么一个简单的脚本在crontab中运行和在shell终端手工运行的结果却不一样。

问题描述

以下是监控脚本/home/watch.sh的内容:

#!/bin/shshell_log_file=/home/start.logpid_count=`pidof video_checkup | wc -w`path=$(cd "$(dirname "$0")"; pwd)run_command="${path}/video_checkup"config_path="${path}/config.json"if [ $pid_count -eq 0  ]; then     echo `date +%Y-%m-%d_%H:%M:%S`" run $run_command $config_path" >> $shell_log_file     $run_command $config_pathelse     echo `date +%Y-%m-%d_%H:%M:%S`" video_checkup already running" >> $shell_log_filefi

在shell终端中执行crontab -e 命令添加如下语句:

1

*/1 * * * *  /home/watch.sh >/dev/null 2>&1

表示该脚本每分钟运行一次,脚本的逻辑很简单就是检查进程video_checkup如不存在则运行之,可是在实际测试中却发现,video_checkup进程不断增多,每分钟都被运行了一次。


问题分析

通过调试发现脚本中 if [ $pid_count -eq 0  ]; then 每次都会进入并执行video_checkup程序,也就是说 $pid_count -eq 0 这个判断每次都是true。将 $pid_count 的值导入到log文件中发现确实是0 。


但是video_checkup明明在运行的啊,不可能是0的,将watch.sh在shell命令行上手工执行却是正常的结果($pid_count就是实际的正在运行的video_checkup进程个数的值)。经过google发现,在crontab计划任务中执行脚本watch.sh的环境变量,和自己ssh登录到shell中手工执行watch.sh的环境变量是不同的,于是乎在watch.sh中加入下面的语句:

echo `export` >> $shell_log_file  并分别在crontab中执行watch.sh,以及在ssh登录的shell中手工执行watch.sh发现果然export的结果不一样。

在crontab中执行watch.sh的时候log文件中显示的export结果中PATH的值是: export PATH="/usr/bin:/bin"
而ssh登录到shell之后手工执行watch.sh之后log文件中显示的export结果中的PATH的值是: PATH="/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin" 这个影响大吗,难道这个PATH变量对 pid_count=`pidof video_checkup | wc -w` 执行的结果会有影响?  


此时我想到有一种可能就是,pidof命令是在哪个目录下?  在ssh的shell环境中执行:

[root@172-28-246-152 video_checkup]# which pidof/sbin/pidof

发现pidof命令是在 /sbin/目录下,也就是说crontab运行的环境中 PATH="/usr/bin:/bin" 目录中根本没有pidof这个命令,那么在crontab中执行 watch.sh中的 pid_count=`pidof video_checkup | wc -w` 就会失败,但是居然连一个错误都没有报告,而且pid_count变量中还被赋值了,难道pidof命令找不到的时候这个语句也能返回值?

我在ssh的shell中构造一个不存在的pidof路径,试一下:

[root@172-28-246-152 video_checkup]# pid_count=`/xx/pidof video_checkup | wc -w`-bash: /xx/pidof: No such file or directory

果然报错说No such file or directory找不到命令,但是此时pid_count中是否有值呢? 再试一下:

[root@172-28-246-152 video_checkup]# pid_count=`/xx/pidof video_checkup | wc -w` && echo $pid_count-bash: /xx/pidof: No such file or directory0

结果彻底清楚了: 由于crontab在后台运行,所以pidof命令不存在,我们根本看不到报错信息,因为报命令不存在的信息是不会被通过管道传递给 wc -w  的,所以可以说出错的时候wc -w没有收到任何输入,但是其执行的结果却是 0 那么变量pid_count的值就是 0 了。 

问题解决

将ssh登录之后的shell环境中的PATH赋值到watch.sh脚本中即可,这样脚本在运行的时候就可以正确找到 pidof 命令得出正确的结果了 (也即在脚本watch.sh的开始处加入代码 PATH="/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin" 即可)

一个小问题居然花了几个小时查清楚原因,可见平时觉得简单的问题在实际应用过程中还是有很多坑的

链接:https://www.cnblogs.com/wangqiguo/p/5399227.html

(版权归原作者所有,侵删)

微信扫码关注该文公众号作者

戳这里提交新闻线索和高质量文章给我们。
相关阅读
linux 定时任务喝茶也有“正确的方法”吗?中年以后最正确的活法:守住自己的能量不负春光(花朵美食图)在Linux中,如何在Linux中使用Ansible进行自动化部署?要确保自己及时站在历史正确的一边比起多说话,会说正确的废话更重要!Lindroid 开源应用:在安卓手机 / 平板上安装 GNU / Linux 发行版普林斯顿北京男孩:4年逃离帝都“内卷中心”到美国读高中,是我最正确的决定重磅!巴菲特股东大会10大看点!股神又赚大了,“只在正确的时候挥杆一击!”Linux 有多重要?这么说吧,只要是干 IT 相关的,学 Linux 是绕不过去的 “ 坎儿 ”Linux 日志管理经验总结( crontab + logrotate )【你的样子】听歌3222元,同价位最正确的配置,i5-12490F、RX6600游戏主机德国大陆集团子公司 Elektrobit 开源基于 Ubuntu 的 Linux 车载操作系统解决方案双胞胎姐妹花携手进牛津剑桥,佛系妈做过最正确的事,是维持家庭“松弛感”!CVPR 2024 | 重新审视并改正小样本3D分割任务中的问题!新benchmark开启广阔提升可能性!挪威哈尔斯塔(Harstad),体验小城第4次探访American Bottom/ㄚㄇㄝㄌㄧㄎㄚ底部《歌德堡变奏曲1552》套用一个 shell 脚本,可助你排查 Linux 系统 CPU 100% 异常问题阿里聚焦主业,是一个非常正确的决定4月起京都花见小路要禁止游客入内了?这才是正确的祗园玩法攻略!掌握了正确的阅读姿势,你也能做到“一目十行”Linux日志管理经验总结(crontab+logrotate)Linux实用技巧:深入解析find命令的运行机制Linux之父 Linus Torvalds 编译 arm64 Linux 内核又有 “ 新欢 ”:Ampere AArch643199元,同价位最正确的配置,i5-12400F、RX6600游戏主机总是做正确的事,能不无聊吗?8.4分!三观不正却吹成神作!这部日本不伦片,每一秒都是禁忌…超实用!满足等保要求的基线核查脚本:linux & Windows只因答不上孩子的问题,母亲竟将三个娃全部勒死?!“小孩的问题都不会,我太没用...”为明年做好准备:IRS预扣税估算器有助于确保2024年预扣正确的税额“6年后回头看,让孩子从名校转入普小,是我做过最正确的决定...”C计划招募「人力HR伙伴」,做难且正确的事情,走向无限可能
logo
联系我们隐私协议©2024 redian.news
Redian新闻
Redian.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Redian.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。