shell定时任务失败主因是cron环境与交互式shell差异，需模拟其极简path、工作目录和环境变量来排查，重点检查日志、路径、权限及重定向。
Shell定时任务（cron job）执行失败，往往不是脚本本身有问题，而是执行环境和上下文差异导致的——cron运行时没有交互式Shell的环境变量、路径、工作目录等。排查核心思路是：模拟cron环境，逐层比对差异。
确认cron是否真正触发了任务
先排除“根本没跑”的情况：
- 检查系统级cron日志：sudo grep CRON /var/log/syslog（Ubuntu/Debian）或 sudo grep cron /var/log/messages（CentOS/RHEL），看对应时间点是否有调度记录
- 在crontab中加简单日志，例如：* * * * * date >> /tmp/cron-test.log 2>&1，确认基础调度通路正常
- 注意用户级crontab和系统级（/etc/crontab）语法不同：前者无用户名字段，后者有；写错格式会导致静默忽略
用cron真实环境复现命令
cron默认使用/bin/sh，且PATH极简（通常只有/usr/bin:/bin）。直接在终端执行成功 ≠ cron能执行成功：
- 手动模拟：运行 env -i PATH=/usr/bin:/bin /bin/sh -c 'your-command'，观察是否报错
- 在crontab中显式指定完整路径：比如用/usr/bin/python3而非python3，用/home/user/script.sh而非./script.sh
- 脚本开头加上#!/usr/bin/env bash并确保有可执行权限（chmod +x），但更稳妥的是在crontab里明确调用/bin/bash /path/to/script.sh
检查脚本内部依赖的上下文
常见“本地能跑，cron崩”的原因：
- 工作目录不确定：cron启动时PWD通常是用户家目录，脚本中用相对路径（如./data/input.txt）会找不到文件。解决方法：脚本开头加cd "$(dirname "$0")" 或用绝对路径
- 环境变量缺失：比如JAVA_HOME、PYTHONPATH、自定义PATH等。可在crontab中提前导出：PATH=/usr/local/bin:/usr/bin:/bin JAVA_HOME=/usr/lib/jvm/default-java
- 需要TTY或交互输入：含sudo、ssh免密未配置、gpg解密等操作，在非交互环境下会卡住或失败。避免在cron中使用需交互的命令
让错误“看得见”——日志和重定向必须做
cron默认只邮件通知标准错误（且常被忽略），务必主动捕获输出：
- 每条crontab命令末尾加上 >> /path/to/log.log 2>&1，例如：0 2 * * * /home/user/backup.sh >> /home/user/backup.log 2>&1
- 脚本内也建议加日志：开头写set -x（打印执行命令），关键步骤用echo "$(date): doing X" >> $LOG
- 测试阶段可临时把命令改成sleep 10 && your-command，然后用ps aux | grep your-command观察进程是否存在，判断是卡住还是秒退
