linux查看cron调试日志需组合四类日志源：一、启用rsyslog的cron设施记录调度行为；二、用journalctl -u crond过滤cmd/pam/failed等上下文；三、在crontab中重定向脚本输出至独立日志捕获stderr/stdout；四、临时调高cron_loglevel=8（慎用）。
Linux 中查看 cron 服务的详细调试日志，核心在于提升日志级别 + 捕获完整执行上下文。系统默认日志通常只记录“是否触发”，不包含环境、权限、PATH 或脚本内部错误细节。要看到真正有用的调试信息，需组合启用以下几类日志源：
一、启用并检查 rsyslog 的 cron 设施日志
这是获取基础调度行为（谁、何时、执行了什么命令）最直接的方式：
- 确认
/etc/rsyslog.d/50-default.conf或/etc/rsyslog.conf中存在未注释行：cron.* /var/log/cron - 若被注释，取消
#后执行：sudo systemctl restart rsyslog - 查看日志：
sudo tail -f /var/log/cron
典型条目如：Jul 29 09:45:01 host CROND[12345]: (root) CMD (/path/script.sh)
→ 这说明任务已调度，但不告诉你脚本里发生了什么。
二、用 journalctl 获取 systemd 级别完整上下文
尤其适用于 CentOS 7+/Ubuntu 16.04+ 等 systemd 系统，比 syslog 更实时、更结构化：
- 查看 cron 服务自身启动与错误：
sudo journalctl -u crond -n 100 --no-pager - 过滤出实际执行命令的记录（含 PAM 认证、环境加载失败等）：
sudo journalctl -u crond | grep -E "(CMD|PAM|failed|denied)" - 实时监控新任务触发及可能的拒绝：
sudo journalctl -u crond -f
→ 常见线索：PAM authentication failure（用户密码过期或 shell 被禁）、Permission denied（crontab 权限错误）、No such file or directory（PATH 缺失导致命令找不到）。
三、为具体任务显式重定向输出到独立日志
系统日志不捕获脚本 stdout/stderr，这是调试失败最常用也最有效的一招：
- 编辑 crontab：
crontab -e - 将原条目：
0 2 * * * /opt/backup.sh
改为：0 2 * * * /opt/backup.sh >> /var/log/backup.log 2>&1 - 确保目标目录可写：
sudo mkdir -p /var/log/backup && sudo chown $USER:$USER /var/log/backup.log
→ 日志中会看到真实报错，比如command not found、Permission denied on /tmp/file、PythonImportError等。
四、临时开启 cron 守护进程调试模式（谨慎使用）
部分发行版支持提高 crond 自身日志粒度（非所有版本都支持）：
- 编辑
/etc/default/cron（Debian/Ubuntu）或/etc/sysconfig/crond（RHEL/CentOS）：
添加或修改：CRON_LOGLEVEL=8 - 重启服务：
sudo systemctl restart cron - 配合 journalctl 查看：
sudo journalctl -u cron | grep -i debug
→ 可能输出环境变量加载过程、shell 启动路径、PAM 模块调用链，但生产环境慎开，日志量大且可能含敏感信息。
不复杂但容易忽略：光看 cron 是否“触发”远远不够，真正的问题几乎都藏在脚本执行时的环境和输出里。优先做第三步（重定向），再结合第二步（journalctl）交叉验证，基本能定位 95% 的问题。
