永远不要 tail -f 管道

运维同事为了收集日志，配置程序将日志写入一个命名管道。然后他在外边拿 tail -f 去读，结果发生了灵异事件。通过 strace 可以看到，tail 进程读取了日志，但是却并没有再输出来。但是如果不启动输出日志的程序，而是在实例启动之后再进去往管道里写数据，却又是可以立即得到 tail 的输出的。

很奇怪的行为，一群人在那里研究半天，猜测是不是环境变量造成的啊，是不是放后台组执行造成的啊，是不是 XYZ 啊。——典型的「霰弹枪式」除错法。

我当时也被带沟里了。于是跑去尝试复现，接着去读 tail 的源码。花了好久才明白这是一个很简单的问题：tail -f 的语义首先是 tail 这个词本身——先读文件最末尾的数据（默认是十行），然后再是 -f 选项的语义，即在文件更新时接着读取数据并输出。所以，当程序往里边写日志时，管道写端一直没关闭，tail 就一直读不到文件结束，也就无法确定最后十行是什么。当他们测试的时候，因为使用的是 echo shell 命令，打开文件、写入数据、关闭。这样 tail 一下子就读取到了文件末尾，然后把数据输出来了。接下来就是边读边输出了。

其实这种使用方法本身就很奇怪了，以至于这个执行流是兼容许多系统的 tail 的各种分支里，最最不常规、无可奈何的那一个分支。你都用管道了，cat 一下嘛。如果怕遇到管道被 reopen 的情况，就在 while true 里 cat 就好。

这个事件中，我也是见识了很多人解决问题的奇怪思路：「我猜猜猜。猜对了哦耶，猜错了，哎呀编程好难啊，Linux 系统好难啊……」猜你妹啊！你长的是大脑又不是骰子，用逻辑一步一步地取得结果不好吗！

有一个小游戏——猜数字。比如甲确定一个 1 到 1000 之内的整数，然后乙来猜。每当乙给出一个猜测时，甲回应猜对了，还是过大或者过小。如果乙知道什么叫二进制的话，乙可以保证在十次之内猜中的。

计算机系统和编程世界里，最棒的一点是确定性和逻辑性。虽然经常也不是像上例那样完全确定的，但至少比起人类社会要容易确定得多。特别是在有源码的时候。所以解决问题的路线也很简单，顺着问题的症状一路回溯，确认然后排除那些没有问题的部分，逐步缩小问题所在的范围，直接你看见它。就跟上边的猜数字游戏或者地毯式搜索一样。每一次猜测都是带着排除一部分没有问题的地方而去，而不是明明有证据表明某个地方不可能有问题，你还偏偏怀疑问题在那里，做无用功。

就像调查一个凶案，这些人放着有作案嫌疑的人不管，非要费劲地去调查那些有相当好的不在场证明的人。

Arch Linux 中文社区这边也有很多这种人。出了问题描述不清楚症状。新手嘛，没经验也没学习过如何描述事实，讲不清楚也没什么，引导对方获取截屏、日志，逐步排查问题就好了嘛。可就是有些热心人，喜欢提出自己的猜测。重点是：都不尝试证实猜测是否属实，就急着上解决方案。结果就是，我询问细节事实的消息没人理，求助者试试这个，试试那个，最终问题能否解决，就跟买彩票能否中奖一样，全凭运气。