type
Post
status
Published
date
Oct 5, 2026
slug
summary
退出码是 0，正文也落了档，可天气、微信、滴答三个子进程一个都没起来。
tags
Write
静默故障
环境变量
排障方法
DSH 排障现场
category
DSH
icon
password
url
有很长一段时间，我每天早上都收到一份「看起来正常」的简报：定时器按时触发，退出码是 0，正文老老实实落在档里。直到某天我顺手翻了一下投递记录，才发现那三个真正对外的出口——天气、微信、滴答——已经连着好几天一个都没动静。
我写这篇，是因为这个故障最反直觉的地方不在「坏了」，而在「坏了却处处显示健康」。它让我重新审了一遍自己对「日志没有报错」这件事的信任。
一、退出码 0 是怎么骗过我的
先说这套东西的结构。一个主脚本负责拼装当天的简报正文，拼好之后，再分别去调三个子进程：拉天气、推微信、写滴答。主脚本是被人用绝对路径直接拉起来的，所以它自己从来不会找不到自己。
问题就出在这三个子进程上。主脚本里起它们的时候，用的是裸的
node 这个词，而不是一个确定的解释器路径。在我手动敲命令的终端里，这没有任何问题——终端的 PATH 很全，node 一找就有。但定时器给我的是一个极简环境。极简到什么程度？我后来实测了一下，那个环境里继承下来的变量只有一两个和认证相关的东西，连 PATH 都没有。没有 PATH，就意味着「
node」这个词在系统眼里根本不是一个可执行的程序名，三个子进程全部以 ENOENT 收场。而主脚本对此毫无察觉。它把子进程起失败这件事吞了下去，继续往下走，正常收尾，正常退出。于是退出码是 0，正文也落了档。从外面看，一切绿灯。
二、最有欺骗性的一层：主脚本是好的
我一开始的判断是错的。我看到退出码 0、看到正文在，第一反应是「投递环节出问题了」，于是去查微信那边的接口、查网络、查凭据。查了一圈没有结论，因为问题根本不在投递，而在「投递这件事压根没被发起」。
真正让我转向的，是我意识到主脚本和子进程活在两个不同的环境假设里。主脚本是被绝对路径拉起来的，所以它对环境的依赖几乎为零；子进程是被「名字」拉起来的，所以它对环境的依赖是百分之百。一个进程里，两种启动方式并存，就出现了这种「一半健康、一半全灭」的状态。
这也是我觉得这个坑值得写下来的原因：它不是「配置漏了一项」那么简单，而是同一个脚本里，不同子进程的启动方式决定了它们对环境的敏感度完全不同。你只要有一处用了裸名字，那一处就会在极简环境里静默死掉，而且死得毫无声响。
三、三层修复，从根上堵
想清楚之后，修复分了三层，从最根本的往外铺。
第一层，也是最根本的一层：所有子进程统一用当前进程自己的解释器路径来启动，也就是
process.execPath。这个概念很简单——不要问系统「node 在哪」，而是直接说「用正在跑我的这个解释器」。这样无论父进程是被谁、在什么环境里拉起来的，子进程都能拿到一个确定可用的解释器。这一层改了好几处。第二层，给两个定时任务的配置文件显式声明 PATH。这是防御性的：万一将来还有别的地方依赖 PATH，至少环境里有一个合理的默认值兜底。
第三层，让简报本身带一个兜底逻辑，在特定系统上能自己找到可用的运行时。这层是最后一道保险，不是主力。
修完之后我做了两轮验证。一轮是用最小环境去模拟定时器的处境，确认子进程能起来；另一轮是真实的端到端投递，确认微信那边真的收到了。只有第二轮过了，我才敢说修好了。
四、日志里没出现那一行，不等于代码没执行
修这个故障的过程中，我还顺手挖出另一个会误导排障的问题，它比第一个更隐蔽。
我前一天曾经排查过一次「兜底提示没写进日志」的现象，当时的结论是「兜底那段代码根本没被执行」。这个结论是错的。真实原因是：那个负责推送的脚本在结束时用了强制退出的方式，而标准输出里还有内容没来得及刷盘，就被这次退出直接丢掉了。代码执行了，只是它说的话没能留下来。
这件事给我的教训，比第一个故障还重：日志里没有出现某一行，不能反推「那段代码没执行」。它可能执行了，只是输出在进程结束的瞬间丢了。从那以后，我判断一段逻辑有没有跑，不再只看日志里有没有那句话，而是看它有没有留下别的、更硬的痕迹——比如有没有产生副作用、有没有写进别的存储。
五、顺带确认的一件事：不是所有定时器都会补跑
修完之后我重新梳理了一遍本机所有「到点会跑」的机制，因为这次故障让我意识到，我对它们的假设可能一直是错的。
结论是它们分成好几类，行为完全不同。系统级的定时任务，在机器睡眠唤醒之后，会把错过的那一次补上；但如果机器是关机错过的，就不补。而挂在应用进程里的那类定时器，机制上就是「错过不补」——只要两次检查之间的间隔超过一个阈值，它会直接把所有已经过期的触发点跳过，既不建执行记录，也不更新触发时间戳，界面上却依然显示「已启用」，下次运行时间还天天在往前推。
这就构成了另一种「假健康」：它看起来一直在正常调度，实际上该跑的那几次早就被静默跳过了。我后来把「要保证到点一定跑」的任务，统一挪到了系统级定时器上，就是因为这个区别。
六、可以搬走的几条判据
把这次故障里能复用的东西抽出来，大概是这么几条：
- 定时任务里的所有子进程，统一用当前进程自己的解释器路径启动，不要依赖 PATH。父进程被绝对路径拉起，不代表子进程也能靠名字找到东西。
- 「退出码 0」只说明主流程没抛异常，不说明它做的事都成功了。如果子进程的失败被吞掉，主流程照样能体面收尾。
- 日志里没有某一行，不能反推那段代码没执行。进程结束时的强制退出会丢掉还没刷盘的输出，判断执行与否要看副作用，而不是看日志。
- 同一个脚本里混用两种启动方式，会产生「一半健康、一半全灭」的假象。启动方式决定了这个子进程对环境的敏感度，混用就是给自己埋雷。
- 改完定时任务，要用最小环境模拟加真实端到端两轮验证。只跑一轮模拟，你验证的是「它能不能起来」，不是「它到底有没有把事办成」。
最后一条是我这次最想强调的：这个故障从头到尾没有报过一次错，它只是一直安静地什么都不做。对自动化来说，最危险的状态从来不是崩溃，而是「看起来一切正常」。