为何crontab不执行

时间 2019-11-06

标签为何 crontab 执行繁體版

原文原文链接

原文地址： https://www.tony-yin.site/201...

做为linux中的定时任务工具，crontab被广大开发者所热爱和使用。该技术由来已久，至关成熟，可是在真正使用的时候会时不时地发现为何crontab脚本没有按照预期那样执行？本文以本周笔者遇到一个crontab不能运行的问题为引子，详细地介绍为何crontab不运行的各类缘由。html

引子

本周遇到一个crontab不能执行的问题，发现缘由后以为甚是有趣。python

笔者经过一个python脚本向/etc/cron.d目录下的一个文件写入定时任务命令，每分钟调用一个脚本，调用的这个脚本是个python文件，而后发现cron并无按照预期每分钟执行一次。而后笔者就将原定时任务脚本aaa拷贝了一份，并从新命名为bbb，而后将定时任务中调用脚本改为了执行一个简单的echo命令，而后保存退出，发现bbb是能够正常定时运行的，这时候，笔者就经过file命令想比较一下这两个文件有何不一样：linux

[root@tony cron.d]# file *
aaa:     ASCII text, with no line terminators
bbb:     ASCII text

这个时候咱们能够发现aaa文件出现了比较奇怪的标识：git

with no line terminators

显而易见，这是在说cron脚本中定时命令没有行终止符，致使这个问题是由于该cron脚本由python代码生成时没有添加换行符：github

with open('/etc/cron.d/aaa', 'w') as f:
    f.write('xxx')

而后笔者尝试性地在aaa文件中在定时命令下新增一行后，发现定时任务能够正常运行了。不得不说，这是一个颇有意思的问题，crontab竟然会由于一个换行符致使定时任务的不运行，后来google了一下发现，crontab的确存在这个机制，具体解释下面会提到。shell

在google的同时，在ask unbuntu上发现了这篇文章：《Why crontab scripts are not working?》，里面不少开发者罗列了他们遇到cron不能正常运行的各类因素，笔者大体浏览了下，发现有遇到过，也有不少并不知道的，因此想把这些因素和解决方案一一罗列下来。ubuntu

因素

因素1：环境变量

场景及缘由

cron中的环境变量和系统的环境变量是不同的，咱们能够经过设置定时脚本将cron中的环境变量打印出来：windows

* * * * * env > /tmp/env.output

能够看到cron中的环境变量：安全

XDG_SESSION_ID=12952
SHELL=/bin/sh
USER=root
PATH=/usr/bin:/bin
PWD=/root
LANG=en_US.UTF-8
SHLVL=1
HOME=/root
LOGNAME=root
XDG_RUNTIME_DIR=/run/user/0
_=/usr/bin/env

查看系统的环境变量：bash

[root@tony cron.d]# env
XDG_SESSION_ID=1140
HOSTNAME=tony
TERM=xterm-256color
SHELL=/bin/bash
HISTSIZE=1000
USER=root
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin:/root/bin
MAIL=/var/spool/mail/root
PWD=/etc/cron.d
LANG=en_US.UTF-8
TMUX_PANE=%18
HISTCONTROL=ignoredups
SHLVL=2
HOME=/root
LOGNAME=root
_=/usr/bin/env
OLDPWD=/root

咱们能够看到cron中的环境变量不少都和系统环境变量不同（cron会忽略/etc/environment文件），尤为是PATH，只有/usr/bin:/bin，也就是说在cron中运行shell命令，若是不是全路径，只能运行/usr/bin或/bin这两个目录中的标准命令，而像/usr/sbin、/usr/local/bin等目录中的非标准命令是不能运行的。

这个问题笔者也遇到不少次，因此不少非标准命令都选择了全路径，可是这个方法也有问题，由于不一样环境的命令所存在的目录是不同的。

解决方案

方案1：

在cron脚本文件头部声明PATH

#!/bin/bash
PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

# rest of script follows

方案2：

在定时脚本调用的脚本头部声明PATH

PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

15 1 * * * backupscript --incremental /home /root

因素2：换行符

场景及缘由

这个因素就是笔者引子中提到的，官方解释（man crontab）以下：

Although cron requires that each entry in a crontab end in a newline character, neither the crontab command nor the cron daemon will detect this error. Instead, the crontab will appear to load normally. However, the command will never run. The best choice is to ensure that your crontab has a blank line at the end.

4th Berkeley Distribution      29 December 1993     CRONTAB(1)

简单翻译一下就是：

尽管crontab要求cron中的每一个条目都要以换行符结尾，但crontab命令和cron守护进程都不会检测到这个错误。相反，crontab将正常加载。然而，命令永远不会运行。最好的选择是确保您的crontab在末尾有一个空白行。

解决方案

给cron中每一个条目下面添加一个空行

注意：

除了没了换行符会致使cron中的命令不会运行，即引子中所标识：

with no line terminators

可是由于非linux操做系统致使的非\n换行符一样会致使该问题，好比windows的^M、mac的\r等

with CR line terminators

解决方案：

windows的话就经过dos2unix命令转换；而mac则能够经过mac2unix来转换，mac2unix也是dos2unix软件中的一部分

Refer

remove CR line terminators

因素3：crond 服务

场景及缘由

不少时候crond服务未开启，也会致使定时任务不会正常执行。

解决方案

查看服务是否运行，若是未运行，启动crond服务便可。

查看方式有两种：

1.经过进程查看

pgrep至关于ps -ef | grep

pgrep cron

2.经过service查看

service crond status

启动服务：

service crond start

因素4：shell 解释器

场景及缘由

从因素1就知道cron环境变量中的SHELL是sh而不是bash，咱们知道不少shell命令是能够在bash中正常运行，可是不能在sh中运行的，因此这个因素也会影响定时任务的正常运行。

解决方案：

方案1：

将cron中须要执行的命令在sh中执行确认

方案2：

将cron中须要执行的命令外面加一个bash shell的封装：

bash -c "mybashcommand"

方案3：

修改cron中的SHELL环境变量的值，让全部命令都用bash解释器：

SHELL=/bin/bash

方案4：

若是定时任务执行的命令是shell脚本，只要在脚本内添加bash解释器：

#!/bin/bash

因素5：时区

场景及缘由

当修改系统时区后，不管是以前已经存在的cron仍是以后新建立的cron，脚本中设置的定时时间都以旧时区为准，好比原来时区是Asia/Shanghai，时间为10:00，而后修改时区为Europe/Paris，时间变为3:00，此时你设置11:00的定时时间，cron会在Asia/Shanghai时区的11:00执行。

解决方案：

方案1：

重启crond服务

service crond restart

方案2：

kill crond进程，由于crond进程是可重生的

因素6：百分号%

场景及缘由

当cron定时执行命令中，有百分号而且没有转义的时候，cron执行会出错，好比执行如下cron：

0 * * * * echo hello >> ~/cron-logs/hourly/test`date "+%d"`.log

会有以下报错：

/bin/sh: -c: line 0: unexpected EOF while looking for matching ``'
/bin/sh: -c: line 1: syntax error: unexpected end of file

有的日志也会有以下报错：

(echo) ERROR (getpwnam() failed)

crontab manpage中解释：

The "sixth" field (the rest of the line) specifies the command to be run. The entire command portion of the line, up to a newline or % character, will be executed by /bin/sh or by the shell specified in the SHELL variable of the cronfile. Percent-signs (%) in the command, unless escaped with backslash (\), will be changed into newline characters, and all data after the first % will be sent to the command as standard input.

即cron中换行符或%前的命令会被shell解释器执行，可是%会被认为新一行的字符，而且%后全部的数据都会以标准输出的形式发送给命令。

解决方案

为百分号作转义，即在%前添加反斜杠\

Refer

因素7：密码过时

场景及缘由

Linux下新建用户密码过时时间是从/etc/login.defs文件中PASS_MAX_DAYS提取的，普通系统默认就是99999，而有些安全操做系统是90。更改此处，只是让新建的用户默认密码过时时间变化，已有用户密码过时时间仍然不变。

当用户密码过时也会致使cron脚本执行失败。

解决方案

将用户密码有效期设置成永久有效期或者延长有效期

方案1：

chage -M <expire> <username>

方案2：

passwd -x -1 <username>

方案3：

手动修改/etc/login.defs文件中PASS_MAX_DAYS的值

因素8：权限

场景及缘由

不少时候解决方案都是采用root用户执行cron，可是有时候这并非一个很好的方式。若是采用非root用户执行cron，须要注意不少权限问题，好比cron用户对操做的文件或目录是否存在权限等。

若是权限不够，cron会拒绝执行：

sudo service cron restart
grep -i cron /var/log/syslog|tail -2
2013-02-05T03:47:49.283841+01:00 ubuntu cron[49906]: (user) INSECURE MODE (mode 0600 expected) (crontabs/user)

解决方案

# correct permission
sudo chmod 600 /var/spool/cron/crontabs/user
# signal crond to reload the file
sudo touch /var/spool/cron/crontabs

因素9：不一样平台

场景及缘由

一些特殊选项各个平台支持不同，有的支持，有的不支持，例如2/3、1-5、1,3,5

解决方案

须要针对不一样平台作兼容性测试

因素10：不一样 cron

场景及缘由

将以前运行的Crontab Spec在从一个Crontab文件移动到另外一个Crontab文件时可能会崩溃。有时候，缘由是你已经将Spec从系统crontab文件转移到用户crontab文件，反之亦然。

cron分为系统cron和用户cron，用户cron指/var/spool/cron/username或/var/spool/crontabs/crontabs/username，系统cron指
/etc/crontab以及/etc/crontab，这二者是存在部分差别的。

系统crontab在命令行运行以前有一个额外的字段user。这会致使一些错误，好比你将/etc/crontab中的命令或者/etc/cron.d中的文件移动至用户crontab会报错以下：

george; command not found

相反，当发生相反的状况时，cron将显示/usr/bin/restartxyz is not a valid username之类的错误。

解决方案

当共享系统cron或用户cron时，注意用户的添加和删除。

因素11：crontable 变量

场景及缘由

虽然你能够在crontable里面声明环境变量，可是在下面这种状况定时任务是不会执行的：

SOME_DIR=/var/log
MY_LOG_FILE=${SOME_LOG}/some_file.log

BIN_DIR=/usr/local/bin
MY_EXE=${BIN_DIR}/some_executable_file

0 10 * * * ${MY_EXE} some_param >> ${MY_LOG_FILE}

这是由于在crontable里面只能声明变量，不能对变量进行操做或者执行其余任何shell命令的，因此上述的shell字符串拼接是不会成功的，因此只能声明变量，而后在命令中引用变量。

解决方案：

方案1：

直接声明变量

SOME_DIR=/var/log
MY_LOG_FILE=/var/log/some_file.log

BIN_DIR=/usr/local/bin
MY_EXE=/usr/local/bin/some_executable_file

0 10 * * * ${MY_EXE} some_param >> ${MY_LOG_FILE}

方案2：

声明多个变量，在命令中引用拼接

SOME_DIR=/var/log
MY_LOG_FILE=some_file.log

BIN_DIR=/usr/local/bin
MY_EXE=some_executable_file

0 10 * * * ${BIN_DIR}/${MY_EXE} some_param >> ${SOME_DIR}/${MY_LOG_FILE}

因素12：GUI

场景及缘由

若是你的cronjob调用了相关GUI应用时，你须要告诉它们应该使用什么DISPLAY环境变量，从因素1咱们能够知道cron中的环境变量是和系统环境变量不同的，DISPLAY一样如此，好比

Firefox launch with cron.

解决方案

声明DISPLAY=:0

* * * * * export DISPLAY=:0 && <command>

总结

目前主要总结了影响cron运行的12种因素，固然确定还存在其余影响因素，本文将持续更新，但愿这些坑可以被广大开发者所熟知。

你们若是有上述之外致使cron不能正常运行的因素能够在博客下方留言，或者在Github上面提pr，笔者已经将本文在Github上面建立了一个仓库，让咱们一块儿不断完善吧 -。-

Github仓库地址：https://github.com/tony-yin/W...