关键不是找错误，而是让失败显形：需强制捕获stdout/stderr、模拟cron环境执行、检查脚本健壮性（如set -e/-u）、启用并查看系统级cron日志。
排查运维脚本中的静默失败，关键不是“找错误”，而是“让失败显形”。很多脚本在 cron 或后台运行时看似没动静，其实已经崩溃或跳过关键逻辑——只是没人看到输出、没人收到退出码、也没人检查返回值。下面从最常被忽略的四个实操点切入。
强制捕获全部输出（stdout + stderr）
默认情况下，cron 不会保存任何输出，错误信息（比如 Python 的 ImportError、bash 的 command not found）全走 stderr，而它默认被丢弃。不重定向，就等于没日志。
- 在 crontab 中务必加上 2>&1：
0 2 * * * /usr/local/bin/backup.sh > /var/log/backup.log 2>&1 - 不要只写
> /path/log，漏掉 stderr 就等于关掉了最重要的诊断窗口 - 日志文件路径需确保目标目录存在、有写权限；建议用绝对路径，避免因 cron 工作目录不确定导致写入失败
模拟 cron 环境执行脚本
cron 启动的是一个极简 shell（通常是 /bin/sh），PATH 很窄（常见只有 /usr/bin:/bin），不加载 .bashrc/.profile，也不认识 ~。手动能跑 ≠ cron 能跑。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 用这条命令精准复现 cron 执行环境：
sudo -u youruser env -i PATH=/usr/bin:/bin /bin/sh -c '/path/to/script.sh' - 如果报错 “command not found”，说明脚本里用了未加绝对路径的命令（如
python3→ 改成/usr/bin/python3） - 如果报错 “No such file or directory”，检查是否含 Windows 换行符（
cat -v script.sh看是否有^M），用dos2unix script.sh修复
检查脚本自身健壮性
静默失败往往源于脚本内部缺乏防御逻辑，比如忽略命令退出状态、不校验前置条件、不设超时。
- 在关键命令后加判断：
mysql -e "SELECT 1" &>/dev/null || { echo "DB unreachable"; exit 1; } - 开头加
set -e（遇到非零退出立即终止），加set -u（引用未定义变量时报错），避免“一路错到底还假装成功” - 涉及路径操作的脚本，开头显式
cd /expected/work/dir或用cd "$(dirname "$0")"切到脚本所在目录，避免相对路径失效
启用并查看系统级 cron 日志
有些发行版（如 Ubuntu/Debian）默认关闭 cron 日志；Amazon Linux、CentOS 需手动开启，否则连“任务是否触发”都无从验证。
- 编辑
/etc/rsyslog.d/50-default.conf，取消注释这行：cron.* /var/log/cron.log - 重启服务：
sudo systemctl restart rsyslog cron - 实时观察：
sudo tail -f /var/log/cron.log | grep CRON
能看到每一行 cron 是否被读取、是否启动子进程、是否返回退出码
