脚本路径和执行权限是crontab静默失败的两大基础坑：必须用绝对路径（如/opt/backup/mysql_backup.sh）调用脚本，且需chmod +x赋予可执行权限；脚本内命令、配置及日志路径也须绝对化，并确保执行用户对所有资源有对应读写权限。

脚本路径和执行权限是 crontab 定时任务静默失败最常踩的两个基础坑。它们不报错、不提示，只让任务“看起来在跑”，实则什么都没做。

脚本必须用绝对路径调用

crontab 不会自动查找你的脚本，它只认完整路径。写 backup.sh 或 ./backup.sh，cron 默认在 root 用户家目录（/root）或空路径下找，十有八九找不到。

• 正确写法：直接用 /opt/backup/mysql_backup.sh 这类完整路径
• 确认真实路径：运行 realpath backup.sh 或 which backup.sh，别靠记忆或 tab 补全
• 即使脚本和 crontab 属于同一用户，也不能省略路径

脚本文件本身要有可执行权限

crontab 不会解释脚本内容，它只当它是「可执行文件」来调用。没有 x 权限，脚本压根不会启动——crontab -l 能看见任务，/var/log/cron 显示“executed”，但里面 print、touch 全无反应。

• 加执行权：chmod +x /opt/backup/mysql_backup.sh
• 检查权限：ls -l /opt/backup/mysql_backup.sh，确保显示 -rwxr-xr-x 或至少当前用户有 x
• Python 脚本也一样：哪怕用 python3 script.py 方式调用，脚本本身最好也有 +x，避免混淆

脚本内部命令和路径也要绝对化

脚本能启动，不代表它能跑完。内部调用的 mysqldump、rsync、tar，或读写的 config.json、logs/，都可能因环境不同而失效。

• 命令用绝对路径：/usr/bin/mysqldump、/bin/tar，别只写 mysqldump
• 查真实位置：which mysqldump 或 find /usr -name mysqldump 2>/dev/null
• 开头就切工作目录：cd /opt/backup || exit 1，再用相对路径才安全；否则所有路径都建议写绝对路径，比如 /backup/logs/

权限与执行用户要严格匹配

谁的 crontab，就以谁的身份运行。root 的任务用 root 权限执行，普通用户任务默认用该用户身份运行。权限错位会导致数据库连不上、配置文件读不到、日志写不进目录等静默失败。

• 确认脚本归属：ls -l /opt/backup/mysql_backup.sh，确保执行用户有读+执行权限
• 若用 ~/.my.cnf 存数据库密码，该文件必须属于对应用户，且权限为 600
• 避免在脚本里用 sudo 或交互式密码输入——cron 不支持等待