关于linux:linuxcrontab任务配置失败原因总结和技巧

37次阅读

共计 1028 个字符,预计需要花费 3 分钟才能阅读完成。

原创:linux_crontab 工作配置失败起因总结和技巧

 昨天,配置 crontab 时遇到一些坑。crontab 尽管算比拟相熟了,但也有 1 年多没碰过,有点陌生了,低级谬误根本又犯了一遍。顺便整顿下。

如果配置了 crontab,之后没有失效,怎么办?
依照如下程序解决:
1,命令独自拿进去,终端中执行
这个能够暴露出如下问题
a,脚本是否存在权限问题 (chmod +x xx.sh)
b,是否存在(手抖) 写错门路等低级谬误
c,如果依赖特定 conda 环境,则须要 conda activate xxx

2,是否应用相对路径
如果 1 执行 ok,则
a, 查看命令中的 x.sh 等换成 /home/xxx/x.sh 等绝对路径,y.py 也一样,用残缺绝对路径.
b, 如果 py 依赖特定 conda,则必须应用 conda 中的特定 py,
上面就是 conda 的 center 环境的 python

 /home/john/anaconda3/envs/center/bin/python  xx.py

3,是否启动了 crontab 服务

办法 1,每次批改 crontab 主动回显:crontab: installing new crontab, 阐明启动了服务
john@VM-0-4-ubuntu:~$ crontab  -e
crontab: installing new crontab

办法 2
service cron status
上面会显示 activate(running)相似字样 

4,check 下服务器工夫,国外默认工夫和国内存在时差(查工夫命令(linux):date)
5, 查看工夫配置规定,是否正确(右到左,周年月时候,没啥说的)
6, 查看 cron 执行日志(是否 xx 工夫启动 xx 命令)

sudo tail -20f /var/log/cron.log 

如果这个文件不存在呢?

sudo vim /etc/rsyslog.d/50-default.conf
找到 cron 开始的行,后面的正文符号 #去掉

7,字符本义,这个是昨天才留神到的,之前本人执行数据库备份工作都是 py 脚本,主动实现依照日期备份,避免同名笼罩。才留神到 crontab 也反对命令中夹杂变量。简略的备份就不必通过 py 脚本实现了。

终端中:now = date +%Y%m%d && tar -xzvf xx_$now.tar.gz xxx/
crontab:now = `date +\%Y\%m\%d` && tar -xzvf xx_$now.tar.gz xxx/

留神 ”%” 前的本义的 ”\”, 和内部那个非单引号,而是键盘上部 1 右边那个按键.

正文完
 0