sudo环境下Cron定时任务无法执行Bash脚本问题排查求助

我来帮你拆解下这个问题——手动sudo执行正常，但Cron跑不起来，这种情况我碰到过好几次，大概率是Cron的特殊执行环境和我们日常shell环境的差异导致的，下面是几个你可以逐一排查的方向：

• 绝对路径的坑：Cron里的~不是你以为的那个路径
  你用sudo crontab -e编辑的是root用户的Cron任务，这里的~指向的是/root目录，而你的脚本实际在/home/myuser/nightly_backup.sh，所以Cron执行时根本找不到脚本！这是最常见的问题之一。
  解决方法：把Cron命令里的路径改成绝对路径，比如：

  0 4 * * * bash /home/myuser/nightly_backup.sh
  

  或者如果你的脚本开头已经加了#!/bin/bash并且给了执行权限（chmod +x /home/myuser/nightly_backup.sh），可以直接写：

  0 4 * * * /home/myuser/nightly_backup.sh
  

• 检查Cron的执行日志，定位具体错误
  Cron默认不会主动给你报错提示，得自己去挖日志。不同系统的日志位置不一样：

  • Ubuntu/Debian系列：查看/var/log/syslog，过滤Cron相关内容：

    grep CRON /var/log/syslog
    

  • CentOS/RHEL系列：直接查看/var/log/cron
    日志里会明确告诉你是找不到脚本、权限不足还是脚本内部命令执行失败，这是快速定位问题的关键。

• 脚本内部命令的环境变量问题
  Cron的执行环境PATH非常有限，默认可能只有/bin:/usr/bin，而你手动执行时的shell环境里有更多路径（比如/usr/local/bin）。如果你的脚本里用到了一些不在默认PATH里的命令（比如自定义工具、特定版本的数据库客户端），就会执行失败。
  解决方法选一种就行：

  1. 在脚本里给所有命令加上绝对路径，比如用/usr/local/bin/mysqldump代替mysqldump；
  2. 在Cron任务开头设置PATH，比如：

     0 4 * * * PATH=/usr/local/bin:/bin:/usr/bin /home/myuser/nightly_backup.sh
     

  3. 在脚本开头导入用户的环境变量（比如source /home/myuser/.bashrc），不过这种方式要注意避免引入不必要的交互内容。

• 确认脚本的执行权限和相关目录权限
  虽然你手动sudo执行正常，但还是要确认两点：

  • 脚本本身有执行权限：ls -l /home/myuser/nightly_backup.sh，确保输出里有x权限（比如-rwxr-xr-x）；
  • 脚本需要读写的目标目录（比如备份存储文件夹）对root用户有足够权限，避免出现“Permission denied”的隐性错误。

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