Linux crontab 有触发却没产物怎么办：把日志、路径和环境补齐

凌晨的报表任务在 cron 日志里明明出现过，早上却没有看到 report.out，遇到这种情况不用急着重写脚本。更靠谱的排查顺序是：确认任务确实被触发，再把标准输出和错误输出写进日志，然后补齐运行路径、命令绝对路径和 PATH。大多数“手动能跑、定时没产物”的问题，都能在这几步里露出线索。

先分清：没触发，还是触发后没产物

排查 crontab 时，最容易把两个问题混在一起：任务根本没有触发，以及任务触发了但脚本中途失败。前者要看服务状态、运行用户、时间表达式；后者要看运行环境、日志和文件路径。

在 Debian、Ubuntu 这类系统上，服务名常见是 cron；在 CentOS、Rocky Linux、AlmaLinux 这类系统上，服务名常见是 crond。先确认服务状态，再看系统日志里有没有对应记录。

sudo systemctl status cron
sudo systemctl status crond

sudo tail -n 100 /var/log/syslog | grep CRON
sudo tail -n 100 /var/log/cron

如果日志里完全没有这条任务，先回到用户和时间表达式检查；如果日志里有任务记录，说明调度链路已经走到命令入口，接下来就该盯住脚本自己的运行证据。

crontab -l 能看到任务，还要确认用户是否一致

很多线上问题不是命令写错，而是任务写到了另一个用户下面。比如开发同学用 deploy 用户手动测试，最后却用 root 写了定时任务；脚本读到的配置、权限和运行路径都会变。

whoami
crontab -l

sudo crontab -l
sudo -u deploy crontab -l

这里别只看“有没有一条类似的任务”，还要看运行用户是否和脚本需要的权限一致。备份脚本需要读业务文件夹，报表脚本需要写结果文件，用户一换，文件权限就可能变成真正的故障点。

给任务加日志，别让错误静默消失

如果任务有触发记录却没有产物，先把输出收住。很多脚本在终端里报错很明显，放进 crontab 后没有人盯屏幕，错误就像没发生一样。

*/5 * * * * /usr/bin/bash /srv/report/run_report.sh >> /var/log/report-cron.log 2>&1

等下一次触发后，直接看日志：

sudo tail -n 80 /var/log/report-cron.log

如果看到 No such file or directory，先查路径；如果看到命令找不到，先查 PATH；如果看到权限不够，先查运行用户和目标文件夹权限。日志的价值在于把猜测变成可落地的排查证据。

把运行路径写清楚，相对路径才不会漂

手动运行脚本时，我们通常已经站在项目路径里；crontab 运行时却不一定。脚本里如果用了 ./config.yaml、logs/report.log、output/report.out 这类相对路径，就很容易在定时环境下找不到文件。

更稳妥的写法是先切到项目路径，再调用脚本：

SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

*/5 * * * * cd /srv/report && /usr/bin/bash ./run_report.sh >> /var/log/report-cron.log 2>&1

这里有两个细节很关键：cd /srv/report 让相对路径回到项目基准；/usr/bin/bash 用的是明确路径，不依赖登录会话里的命令查找结果。

PATH 不够时，手动正常不代表定时正常

登录终端会读取一批 shell 配置，crontab 的环境却很精简。脚本里调用 node、python3、mysql、rsync 这类命令时，终端能找到，不代表定时任务也能找到。

先用 command -v 找到真实路径，再写进任务或脚本里：

command -v python3
command -v mysql
command -v rsync

如果团队里有多台机器，建议把关键命令路径和必要环境变量放在脚本开头，并在日志里打印一行启动信息。以后排查时，能立刻知道脚本用的是哪套环境。

修复后不要只等结果，要做反向验证

改完 crontab 后，可以先把频率临时调短，例如一分钟一次，观察日志是否新增，再确认产物是否落到目标文件夹。确认无误后，再改回正式时间。

* * * * * cd /srv/report && /usr/bin/bash ./run_report.sh >> /var/log/report-cron.log 2>&1

反向验证时看三件事：系统 cron 日志里有触发记录，脚本日志里有启动和结束记录，目标文件夹里有新的产物文件。三项都满足，才算这条任务真的恢复正常。

排查清单：按服务、用户、路径、日志四层走

遇到类似问题，可以按下面这组顺序查。它不花哨，但足够覆盖大部分生产环境里的 crontab 故障。

• 服务层：确认 cron 或 crond 正在运行，并能在系统日志里看到触发记录。
• 用户层：确认任务写在正确用户下面，脚本读写文件夹的权限也属于这个用户。
• 路径层：命令、脚本、配置文件、输出位置尽量使用绝对路径，或者先切到项目路径。
• 日志层：把输出写进固定日志文件，先看错误，再改配置。

常见问题

为什么手动运行脚本正常，放进 crontab 就没有结果？

最常见原因是环境不同。手动运行时有登录 shell、当前运行路径和完整环境变量；crontab 里这些条件都可能缺失，所以要显式写 PATH、绝对路径和运行路径。

cron 日志在哪个文件里看？

不同发行版不完全一样。Debian、Ubuntu 常见在 /var/log/syslog 里通过 grep CRON 过滤；CentOS、Rocky Linux、AlmaLinux 常见在 /var/log/cron。如果系统使用 journal，也可以配合 journalctl 查看对应服务日志。

crontab 里一定要重启 cron 服务吗？

通常用 crontab -e 保存后，cron 会自动加载当前用户的任务，不需要手动重启服务。只有改了系统级配置、服务异常或日志显示加载失败时，才考虑检查服务状态。

命令里有百分号为什么容易出问题？

cron 会把未转义的 % 当成特殊分隔符处理。复杂命令建议放进脚本文件里，由 crontab 调用脚本；这样比在一行里堆很多符号更容易维护。

小结

crontab 有触发却没产物时，排查重点不是反复猜脚本，而是把运行证据补齐。先确认 cron 日志，再把脚本输出写到固定日志里，随后补上用户、运行路径、绝对路径和 PATH。定时任务在无人值守时能不能稳定跑，靠的就是这些看起来朴素的细节。