周一早上九点半，汽配那个客户电话就来了，说对账文件没收到。我心里咯噔一下，那套跑批系统跑了两年多，凌晨三点定时拉数据、生成对账、推到他们 FTP，一直稳得跟老狗一样。
登上去一看，昨天那个任务的退出码 255，什么都没生成。
日志在 /data/logs/reconcile.log，四十多兆，一天一个文件，从来没人切过，祖传的毛病。我 tail -n 200 一拉，满屏的 Undefined index、Undefined offset，还有一堆 Warning 说什么 null 上调用方法。看着像业务数据脏了，某个字段空着，一路传下去炸了一串。要我说这种连锁报错最讨厌，真正的原因藏在最上面，底下全是尸体。
我先把 memory_limit 从 512M 加到 2G，没用。又去查数据库，怀疑锁表，翻了一遍 innodb status，干干净净，屁锁没有。重启队列、重启 php-fpm、把那个跑批脚本单独手动跑一遍，还是 255。
周二晚上弄到十一点多，我坐在那儿盯着那堆 Warning，越看越觉得是老张当年埋的补丁逻辑在捣鬼。这人在我们这儿干了五年，走的时候留了一堆没注释的神仙代码，出了事先怀疑他准没错。翻了半天，人家那段逻辑清清白白。
周三下午我实在没招了，想着干脆把整个日志从头看一遍，head -n 50 拉出来——第一行就写着：
failed to open stream: No such file or directory in /data/tmp/export/...
那个目录不存在。
我盯着这行看了大概十秒钟，然后想起来了。上周五下午我嫌那台机器磁盘快满了，du 了一圈，看见 /data/tmp 下面挂着几个两三个 G 的旧目录，心想都是临时文件，删了干净，rm -rf 一把梭，还请自己喝了杯咖啡，觉得自己挺能干。
对账跑批的中间文件就写在那个目录里。目录没了，写不进去，后面全崩。三天。
说句公道话，报错第一行就写着，写得明明白白，连路径都给我列出来了。是我自己三天只肯看尾巴，一门心思往业务逻辑上找。这种错误要我说一眼就能看出来，真的，一眼，就是我没往那儿看。
后来我 mkdir -p 补上目录，改了权限，再手动跑一次，三分钟出文件，一切正常。
期间还有个插曲，我周二晚上排查的时候开了个 tumx 分屏，一边看日志一边改脚本，被小年轻看见了问我这是啥，我说这叫终端复用，你们现在都用那种花里胡哨的图形界面，工具好不好用不在界面上。他哦了一声走了，我也不知道他听没听懂。就是那么拼的，tumx。
还有件事我到现在没想明白，那台机器上的日志为什么会攒到四十多兆没切，查了一下 crontab，切割任务确实在里面，但跑的是另一个用户，权限不对，一直是失败的。也就是说这日志三年没切过，只是一直续写没撑爆而已。这个问题我暂时不打算动，动它干嘛，好好地能跑。话说回来，这个问题其实比这次的报错更该修——算了，下周再说。
今天上午客户那边又发消息说文件收到了，还夸了一句系统稳定。我回了个笑脸。稳定，稳定得很，稳定到我自己把临时目录删了三天才找着。