关键不是看“有没有执行”，而是看“执行时发生了什么”：journalctl是最直接突破口，需按服务类型（crond/cron/your-task.service）选用对应命令，聚焦-p 3错误级别、-o cat纯内容、关键词搜索及SELinux/环境线索，并配合重定向日志增强可靠性。
查定时任务失败，关键不是看“有没有执行”，而是看“执行时发生了什么”。journalctl 是最直接的突破口，但得用对命令、盯准目标。
先确认服务名和日志归属范围
定时任务分两类，日志来源不同：
- 如果是 crontab（传统方式），日志来自
crond或cron服务：sudo journalctl -u crond -n 50 --no-pager（RHEL/CentOS）sudo journalctl -u cron -n 50 --no-pager（Debian/Ubuntu） - 如果是 systemd timer（.timer + .service），日志在对应
.service单元里：journalctl -u your-task.service -n 50别查.timer单元——它只记录触发时间，不记录脚本输出 - 如果是 用户级 systemd 定时任务（非 root），必须加
--user：journalctl --user -u your-task.service -n 50
重点抓错误和完整输出
默认 journalctl 只显示 INFO 级别，很多报错藏在 WARNING 或 ERROR 里：
linux-sysadmin
下载
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
- 只看错误级别：
journalctl -u your-task.service -p 3 -n 50（-p 3 表示优先级 3 及以上，即 err/warning） - 同时查标准输出和标准错误：
journalctl -u your-task.service -o cat -n 50（-o cat 去掉时间戳等冗余，专注内容） - 带关键词搜索：
journalctl -u your-task.service --grep "python\|not found\|permission\|failed"
别漏掉环境和权限线索
很多失败不是脚本逻辑错，而是执行环境缺失：
- 检查是否因 SELinux/AppArmor 拦截：
journalctl -u your-task.service | grep -i "avc\|denied\|audit" - 确认用户 HOME 和 UID 是否正确：
journalctl -u your-task.service -o json-pretty | jq 'select(.UID==1001) | .MESSAGE' | head -10（替换为实际 UID） - 对比手动执行和定时执行差异：如果手动能跑通，大概率是 PATH、环境变量或工作目录问题——systemd service 默认工作目录是
/，需在 .service 文件中显式设置WorkingDirectory=/path/to/script
补充：让日志更可靠的小技巧
光靠 journalctl 被动查不够，主动留痕更省力：
- 对 crontab 任务，务必重定向输出：
0 2 * * * /path/to/script.sh >> /var/log/script.log 2>&1 - 对 systemd service，在
[Service]段加上：StandardOutput=journal+console和StandardError=journal+console（确保所有输出进 journal） - 启用用户级 journald 持久化（否则登出后日志丢失）：
mkdir -p ~/.config/systemd/journald.conf，写入[Journal] Storage=persistent，再运行systemctl --user restart systemd-journald
