定时任务没跑先别急着重写：用 crontab、systemctl timer 和日志把定时任务讲清楚

定时任务没按预期跑，是服务器运维里很常见的“哑巴故障”：没有报错弹窗，没有服务崩溃，只是到了时间什么都没发生。很多人第一反应是把任务删掉重写一遍，或者换一种定时方式再试一次，结果往往是旧任务还在后台悄悄跑，新任务又叠加上去，最后同一件事被重复执行，问题反而更乱。先把“任务到底有没有被触发、触发后为什么没成”讲清楚，再动手改，顺序不能反。

第一步先确认任务有没有登记上。crontab 的任务要先用 crontab -l 看当前用户的任务列表，确认那一行真的存在、时间字段没有写错。最常见的错误是时间字段数错位：分、时、日、月、周共五段，少写一段或多写一段，整个任务的执行时间就全变了。还要确认编辑的是哪个用户：root 的任务和普通用户的任务是分开的，在 root 下改完，去普通用户下查当然查不到。系统级任务还要看 /etc/crontab 和 /etc/cron.d/ 里的文件，它们的格式比用户 crontab 多一段执行用户，照搬过去不补用户字段就会报错。

第二步查触发记录，而不是凭感觉猜。cron 每次执行都会留日志，可以用 grep CRON /var/log/cron 或 journalctl -u cron 查最近的触发记录：如果日志里根本没有这条任务，说明调度器没触发，问题在时间表达式或服务本身；如果日志里有触发记录但任务没生效，问题在任务内容。用 systemctl list-timers 能看到 timer 类任务的下次触发时间，timer 没启用（inactive）或时间写成了过去，同样不会跑。先区分“没触发”和“触发了但失败”，排查方向完全不同。

第三步查执行环境，这是定时任务最容易踩的坑。手动在终端跑得通的脚本，放进 crontab 就失败，十有八九是环境差异：cron 的 PATH 很短，which 能找到的命令在 cron 里可能找不到；脚本里用了相对路径，cron 的工作目录又不是脚本所在目录，文件自然读写不到正确位置。稳妥的做法是脚本里用绝对路径，命令也写全路径，或者在脚本开头显式 source 环境配置、cd 到固定目录。需要交互输入、依赖图形界面或 SSH agent 的操作，在 cron 里本来就跑不了，要改成非交互方式。

第四步看任务自己的输出。cron 默认把标准输出和标准错误发邮件，服务器上没配邮件就会悄悄丢掉，等于故障现场被清空了。建议每条重要任务都把输出重定向到日志文件，例如 >> /var/log/myjob.log 2>&1，时间久了再加日志轮转。拿到日志后按“触发了吗、命令找到了吗、路径对了吗、权限够吗”逐项核对，大多数定时任务问题都能定位到其中一步。

最后给一条检查清单：任务登记在正确的用户下吗，时间字段对吗，调度服务在运行吗，触发日志里有记录吗，命令和路径都写绝对了吗，输出落到日志文件了吗。按这个顺序查一遍，定时任务没跑的原因基本就藏不住了，也不用靠反复重写去碰运气。