定时任务没跑，先别怪调度器

前阵子早上到工位，发现昨晚该跑的清理任务没动静。登录上去看，调度器状态正常，日志里也没有报错。那天我先查了调度器，没发现问题，再查任务本身，才发现写法上有毛病。定时任务没跑，多数时候是任务换了环境就跑不起来，调度器本身反而很少出问题。

环境不一样，是最常见的一种。手动执行的时候，shell 里有 PATH，有家目录下的配置，命令一敲就通。定时任务拿到的环境是最小的一套，PATH 里可能没有你要的命令，配置文件也可能读不到。脚本在终端里跑得好好的，放到定时里就悄悄退出，日志里还什么都没有。写脚本的时候把路径写全，命令用绝对路径，或者在脚本开头把需要的环境变量写死，比事后排查省事得多。

相对路径是另一个坑。脚本里写了个相对路径，手动跑的时候人正好站在那个目录里，文件读写都正常。定时任务的当前目录未必是那里，文件可能写到别的地方去了，也可能因为找不到文件直接退出。日志里如果看到 No such file，先看脚本是在哪个目录下被拉起来的。脚本开头先切到固定目录，或者全程用绝对路径，这个问题就没了。

输出没地方去，也会让人误判。定时任务的标准输出和错误默认走邮件，没配邮件地址就直接丢了。任务其实跑了，也报错了，但你看不到，就以为它没跑。给每个定时任务都接一根输出管子，重定向到一个日志文件里，顺手在开头记一行时间。以后查起来，先翻这个文件，不用猜。

时间本身也可能对不上。任务按服务器的时间跑，服务器用的是 UTC，写定时规则的时候按本地时间算，差出来的那几个小时，够让任务在你睡觉的时候跑完，或者在你以为它该跑的时候还没轮到。写规则之前，先在服务器上看一眼现在几点，再换算。

还有一种是脚本在等输入。有些脚本里藏着确认步骤，或者等着读一行输入，手动跑的时候人顺手就回车了。定时跑起来没人回车，脚本就卡在那里，一直等到超时。凡是要进定时任务的脚本，先确认它全程不需要人接话。

我现在排查这类问题，顺序基本固定。先看任务到底跑没跑，翻它自己的输出日志。再看环境和路径，是不是换了地方就找不到东西。最后才去看调度器本身。这三处查完，多数定时任务没跑的原因就有着落了。