CronJob 没有运行

Question

我在 ubuntu 环境中为 root 用户设置了一个 cronjob，方法如下：键入 crontab -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

但是 cronjob 没有运行。我尝试使用 pgrep cron 检查 cronjob 是否正在运行，并给出进程 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

原文由 bor 发布，翻译遵循 CC BY-SA 4.0 许可协议

Answer 1

最后我找到了解决方案。以下是解决方案：-

1. 切勿在要通过 crontab 执行的 python 脚本中使用相对路径。我做了这样的事情： -

    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

1. 永远不要抑制 crontab 代码，而是使用 mailserver 并检查用户的邮件。这可以更清楚地了解正在发生的事情。

原文由 bor 发布，翻译遵循 CC BY-SA 3.0 许可协议

Answer 2

怎么回事？！我的 cronjob 没有运行？！

这是调试未运行 cronjobs 的清单指南：

1. Cron 守护进程是否正在运行？

• 运行 ps ax | grep cron 并寻找cron。
• Debian： service cron start 或 service cron restart

1. cron 工作吗？

• * * * * * /bin/echo "cron works" >> /tmp/file
• 语法正确吗？见下文。
• 您显然需要对要将输出重定向到的文件具有写入权限。 /tmp 中当前不存在的唯一文件名应该始终是可写的。
• 可能还添加 2>&1 以包括标准错误以及标准输出，或单独将标准错误输出到另一个文件 2>>/tmp/errors

1. 该命令是否独立工作？

• 通过在 CLI 上进行试运行来检查脚本是否有错误
• 测试您的命令时，以您正在编辑的 crontab 的用户身份进行测试，这可能不是您的登录名或 root

1. cron 可以运行你的工作吗？

• 检查 /var/log/cron.log 或 /var/log/messages 是否有错误。
• Ubuntu： grep CRON /var/log/syslog
• 红帽： /var/log/cron

1. 检查权限

• 在命令上设置可执行标志： chmod +x /var/www/app/cron/do-stuff.php
• 如果您将命令的输出重定向到文件，请验证您是否有权写入该文件/目录

1. 检查路径

• 检查she-bangs / hashbangs线
• 不要依赖像 PATH 这样的环境变量，因为它们在 cron 下的值可能与交互式会话下的不同。请参阅 如何让 CRON 调用正确的路径

1. 调试时不要抑制输出

• 常用的是这种抑制： 30 1 * * * command > /dev/null 2>&1
• 通过完全删除 >/dev/null 2>&1 重新启用标准输出或标准错误消息输出；或者重定向到您具有写入权限的位置的文件： >>cron.out 2>&1 将标准输出和标准错误附加到调用用户主目录中的 cron.out 。
• 如果您不重定向来自 cron 作业的输出，则守护程序将尝试通过电子邮件向您发送任何输出或错误消息。检查您的收件箱（如果您没有邮件客户端，可能只是 more $MAIL ）。如果邮件不可用，则可能在您的主目录中检查名为 dead.letter 的文件，或者检查输出已被丢弃的系统日志条目。特别是在后一种情况下，可能编辑作业以将重定向添加到文件，然后等待作业运行，并检查日志文件以获取错误消息或其他有用的反馈。
• 如果您试图找出失败的原因，错误消息将在此文件中可见。阅读并理解它。

还是行不通？哎呀！

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.* /var/log/cron.log
  • 重新加载记录器 sudo /etc/init.d/rsyslog restart
  • 重新运行 cron
  • 打开 /var/log/cron.log 并寻找详细的错误输出
• 提醒：当您完成调试时，停用日志级别

1. 运行 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

此语法 仅 适用于 root 用户。普通用户 crontab 语法没有 用户 字段（普通用户不能像其他用户一样运行代码）；

 # Minute  Hour  Day of Month      Month         Day of Week    Command
# (0-59) (0-23)   (1-31)    (1-12 or Jan-Dec) (0-6 or Sun-Sat)

    0       2       *             *                *          /usr/bin/find

crontab 命令

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

原文由 Jens A. Koch 发布，翻译遵循 CC BY-SA 4.0 许可协议