linux查看cron执行日志需分两层：先确认系统级日志是否启用并检查/var/log/cron或syslog中cron记录，再通过重定向（>> /path/log 2>&1）捕获任务自身输出。
Linux 查看 cron 定时任务的执行结果日志，核心是分两层：系统级执行记录（是否触发、以谁身份运行）和任务自身输出（脚本是否成功、报什么错）。光看系统日志往往不够，必须结合任务内部的日志重定向。
确认 cron 日志是否已启用
很多系统（尤其是新版 Ubuntu）默认不单独记录 cron 日志，只混在 syslog 里。先检查 rsyslog 是否把 cron 消息写进独立文件：
- 查看配置：sudo cat /etc/rsyslog.d/50-default.conf（Ubuntu）或 sudo grep "cron\." /etc/rsyslog.conf（RHEL/CentOS）
- 若看到类似 cron.* /var/log/cron 且未被注释，说明已启用；否则取消注释，再运行 sudo systemctl restart rsyslog
- 快速验证：执行 logger -t CRON "test"，然后 sudo tail -1 /var/log/cron 或 sudo grep CRON /var/log/syslog 看能否捕获到
查看系统记录的 cron 执行痕迹
这是最基础的“有没有跑”的证据，但不包含脚本内部输出：
- CentOS/RHEL：sudo tail -20 /var/log/cron
- Ubuntu/Debian：sudo grep CRON /var/log/syslog | tail -20
- 通用实时监控：sudo tail -f /var/log/cron（或 /var/log/syslog）
- 用 journalctl（systemd 系统）：sudo journalctl -u crond -n 30 -f（注意服务名可能是 cron 或 crond）
获取任务自身的完整输出（关键步骤）
系统日志只告诉你“某用户在某时刻执行了某命令”，但不会告诉你脚本里 echo "done" 或 python: command not found 是什么。真正排查失败必须靠这一层：
- 编辑 crontab 时，对每条命令显式重定向输出：
0 2 * * * /path/to/backup.sh >> /var/log/backup.log 2>&1 - 确保目标日志路径可写（如 sudo chown $USER:$USER /var/log/backup.log 或写入 /tmp）
- 脚本开头加 set -x 可记录每行执行过程（调试用，上线建议关闭）
- 避免用 >/dev/null 2>&1——这等于主动丢弃所有线索
补充排查线索（当没日志或日志为空时）
如果上面都做了还是看不到执行痕迹，问题可能不在日志本身：
- 检查 cron 服务是否运行：sudo systemctl status cron（或 crond）
- 确认任务语法正确：crontab -l，特别注意路径是否绝对、星号间有无空格
- 脚本是否有执行权限：chmod +x /path/to/script.sh
- 环境变量差异：cron 默认 PATH 很窄，脚本中要么用绝对路径（如 /usr/bin/python3），要么在 crontab 开头加 PATH=/usr/local/bin:/usr/bin:/bin
- 错误输出可能发到用户邮箱：sudo -u username mail（尤其当没重定向且 MAILTO 未设为空时）
