工作日早7点执行的Cron任务无法运行问题求助

既然你的30 * * * 1-5任务能正常运行，说明Cron服务本身、用户权限这些基础环节是没问题的，咱们聚焦在0 7 * * 1-5这个任务的细节上，一步步排查：

1. 优先核对时区一致性 #

Cron默认使用系统时区，而非你当前登录会话的时区。比如如果系统设置的是UTC时区，那0 7 * * 1-5对应的是UTC时间早7点，换算成你的本地时间可能完全不是你预期的早7点，甚至落在非工作日。

• 用timedatectl（systemd系统）或date命令查看系统时区：

  timedatectl
  # 或者
  date +%Z
  

• 确认系统时区和你预期的执行时区一致，不一致的话调整系统时区即可。

2. 查看Cron执行日志（最关键） #

Cron会把所有任务的触发、执行情况记录到日志里，这是定位问题的核心依据：

• Debian/Ubuntu系列系统：日志在/var/log/syslog，过滤Cron相关记录：

  grep CRON /var/log/syslog
  

• RHEL/CentOS系列系统：日志在/var/log/cron，直接查看即可：

  cat /var/log/cron
  

重点看有没有0 7 * * 1-5对应的条目：

• 如果没有触发记录：说明Cron没识别到这个任务，可能是表达式语法（虽然你验证过，但再检查一遍空格、数字范围）或者crontab文件格式问题；
• 如果有触发但执行失败：日志里会明确给出错误原因（比如脚本路径不存在、权限不足、命令找不到）。

3. 排查Cron的执行环境差异 #

Cron的执行环境和你登录shell的环境完全不同，默认的PATH非常受限，很多你手动能跑的命令，Cron可能找不到：

• 解决方法1：在任务里使用命令的绝对路径，比如把sendmail改成/usr/sbin/sendmail；
• 解决方法2：在crontab开头显式设置环境变量，比如：

  PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
  MAILTO=your@email.com
  

• 解决方法3：用登录shell加载完整环境执行任务：

  0 7 * * 1-5 /bin/bash -l -c "/path/to/your/email_script.sh"
  

4. 确认任务命令的正确性 #

再仔细检查0 7 * * 1-5后面的命令部分：

• 脚本/命令是否用了绝对路径？比如你写的send_email.sh，Cron不知道这个脚本在哪个目录，必须写成/home/your_username/scripts/send_email.sh；
• 脚本是否有可执行权限？用chmod +x /path/to/your/email_script.sh添加执行权限；
• 建议给任务加上输出重定向，方便排查：

  0 7 * * 1-5 /path/to/your/email_script.sh >> /var/log/email_cron.log 2>&1
  

这样不管成功还是失败，都会把输出写到日志里，更容易定位问题。

5. 临时测试任务触发逻辑 #

如果上面的排查都没发现问题，可以临时修改表达式，把任务改成工作日每小时0分执行：

0 */1 * * 1-5 /path/to/your/email_script.sh

看看这个任务能不能正常运行。如果能，说明原表达式0 7 * * 1-5本身没问题，可能是7点这个时间点系统有特殊操作（比如自动备份、负载过高）导致Cron没触发；如果也不能运行，那大概率是脚本本身的问题。

内容的提问来源于stack exchange，提问作者mileven