CronJob没有运行

我已经在ubuntu环境中为root用户设置了cronjob,方法是inputcrontab -e

34 11 * * * sh /srv/www/live/CronJobs/daily.sh 0 08 * * 2 sh /srv/www/live/CronJobs/weekly.sh 0 08 1 * * sh /srv/www/live/CronJobs/monthly.sh 

但cronjon不运行。 我已经尝试检查,如果cronjob正在运行使用

pgrep cron

并给出进程ID 3033.Shell脚本是调用Python文件,并用于发送电子邮件。 运行python文件是好的。 它没有错误,但是cron不运行。 daily.sh文件中包含以下代码。

 python /srv/www/live/CronJobs/daily.py python /srv/www/live/CronJobs/notification_email.py python /srv/www/live/CronJobs/log_kpi.py 

WTF? 我的cronjob不运行?

这里有一个清单指南来调试不运行cronjobs:

  1. Cron守护进程是否正在运行?
    • 运行ps ax | grep cron ps ax | grep cron并寻找cron。
    • Debian: service cron startservice cron restart
  2. cron工作吗?
    • * * * * * /bin/echo "cron works" >> /file
    • 语法正确? 见下文。
  3. 命令是独立工作吗?
    • 通过在CLI上执行空运行检查脚本是否有错误
    • 当测试你的命令时,测试你正在编辑crontab的用户,这可能不是你的登录名或root
  4. cron可以运行你的工作吗?
    • 检查/var/log/cron.log/var/log/messages以查找错误。
    • Ubuntu: grep CRON /var/log/syslog
    • Redhat: /var/log/cron
  5. 检查权限
    • 在命令中设置可执行标志: chmod +x /var/www/app/cron/do-stuff.php
    • 如果将命令的输出重定向到文件,请确认您有权写入该文件/目录
  6. 检查路径
    • 检查她 – 刘海/ hashbangs线
    • 不要依赖像PATH这样的环境变量,因为它们的值在cron下可能与在交互式会话下不一样
  7. 调试时不要抑制输出
    • 常用的就是这个抑制: 30 1 * * * command > /dev/null 2>&1
    • 重新启用标准输出或标准错误消息输出

还是行不通? 哎呀!

  1. 提高cron调试级别
    • Debian的
      • /etc/default/cron
      • 设置EXTRA_OPTS="-L 2"
      • service cron restart
      • tail -f /var/log/syslog来查看执行的脚本
    • Ubuntu的
      • /etc/rsyslog.d/50-default.conf
      • 添加或注释行cron.crit /var/log/cron.log
      • 重新加载记录器sudo /etc/init.d/rsyslog reload
      • 重新运行cron
      • 打开/var/log/cron.log并查找详细的错误输出
    • 提醒:当您完成调试时,停用日志级别
  2. 运行cron并再次检查日志文件

Cronjob语法

 # Minute Hour Day of Month Month Day of Week User Command # (0-59) (0-23) (1-31) (1-12 or Jan-Dec) (0-6 or Sun-Sat) 0 2 * * * root /usr/bin/find 

Crontab命令

  1. crontab -l
    • 列出所有用户的cron任务。
  2. crontab -e ,对于特定用户: crontab -e -u agentsmith
    • 开始您的crontab文件的编辑会话。
    • 当您退出编辑器时,修改后的crontab会自动安装。
  3. crontab -r
    • 从cron假脱机程序中删除您的crontab项,但不从crontab文件中删除。

最后我找到了解决办法。 以下是解决方案: –

  1. 不要在Python脚本中使用相对路径通过crontab执行。 我做了这样的事情: –

     import os import sys import time, datetime CLASS_PATH = '/srv/www/live/mainapp/classes' SETTINGS_PATH = '/srv/www/live/foodtrade' sys.path.insert(0, CLASS_PATH) sys.path.insert(1,SETTINGS_PATH) import other_py_files 
  2. 永远不要压制crontab代码,而应使用mailserver并检查用户的邮件。 这更清楚地了解到底发生了什么。

我想补充2点,我学到了:

  1. 置于/etc/cron.d/中的Cron配置文件不应包含点(。)。 否则,它不会被cron读取。
  2. 如果运行命令的用户不在/ etc / shadow中。 它不会被允许安排cron。

参考文献:

  1. http://manpages.ubuntu.com/manpages/xenial/en/man8/cron.8.html
  2. https://help.ubuntu.com/community/CronHowto

crontab会失败的另一个原因:特殊处理%字符。

从man文件中 :

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

在我的具体情况下,我使用date --date="7 days ago" "+%Y-%m-%d"来为我的脚本生成参数,并且这是无声的。 我终于知道了当我检查syslog并看到我的命令在%符号处被截断时发生了什么。 你需要像这样逃避它:

 date --date="7 days ago" "+\%Y-\%m-\%d" 

在这里看到更多的细节:

http://www.ducea.com/2008/11/12/using-the-character-in-crontab-entries/

我发现用户的crontab没有运行的另一个原因:hosts文件不存在于hosts文件中:

 user@ubuntu:~$ cat /etc/hostname ubuntu 

现在主机文件:

 user@ubuntu:~$ cat /etc/hosts 127.0.0.1 localhost # The following lines are desirable for IPv6 capable hosts ::1 ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters ff02::3 ip6-allhosts 

这是在Ubuntu 14.04.3 LTS上,解决它的方法是将主机名添加到主机文件,所以它类似于这样的东西:

 user@ubuntu:~$ cat /etc/hosts 127.0.0.1 ubuntu localhost # The following lines are desirable for IPv6 capable hosts ::1 ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters ff02::3 ip6-allhosts 

对我来说,解决方案是文件cron试图运行在一个加密的目录中,更具体地说是/ home /上的用户diretory。 尽管crontab配置为root用户,因为在/ home / cron的加密用户目录中运行的脚本只能在用户实际登录时读取该目录。要查看目录是否已加密,请检查该目录是否存在:

 /home/.ecryptfs/<yourusername> 

如果是这样,那么你有一个加密的主目录。

对我的修复是将脚本移动到非加密的目录,everythig工作正常。

在crons没有运行的情况下,我遇到了同样的问题。 我们通过更改权限和所有者由Crons修改root权限,正如我们在crontab和Cronjobs 644中给出的权限

有时,cron需要运行的命令是在cron无法访问的目录中,通常在用户的主目录权限为700且系统中的命令位于该目录下的系统上。