系统与基础设施ibiblio.org
那封跑了 500 英里的邮件
The case of the 500-mile email (2002)
2008 — 2021，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是系统管理员 Trey Harris 于 2002 年写下的经典故障排查故事：某大学邮件系统突然只能向约 500 英里以内的地址发信，更远的一律失败。作者层层排查后，最终发现罪魁祸首是 Solaris 补丁导致 sendmail 的超时值被重置为 0，而邮件连接超时恰好与光速传播延迟在 500 英里处重合，故事兼具技术严谨与荒诞趣味。
为什么经久不衰：它把光速这个宇宙常数与日常运维故障巧妙地联系在一起，既是绝佳的故障排查示范，又足够离奇有趣，因此二十年来反复被翻出重读。
HN 评论精选
这个案例之所以能破案，靠的是准确描述、记录变更和可复现性，并分享了自己类似的诡异故障经历。
就故障而言，这个其实很好解决：问题描述准确、如实报告了变更、问题可稳定复现。相比那些无法可靠复现、报告者还声称什么都没改过的问题，这只是小菜一碟。但每次读还是觉得有趣。我早年也遇到过类似的事：Solaris 2.6 某个补丁版本里 sleep 调用坏了，几乎立即返回，导致系统出现各种怪异行为。还有一次是帧中继专线上的 MTU 问题：开发者在堡垒机上对大目录执行 ls -l 时 SSH 会卡死，最后发现是数据包大小接近 MTU 时触发的线路问题，折腾许久才让运营商更换了远端线卡。
js2查看英文原文
> "When did this start? A few days ago, you said, but did anything change in your systems at that time?" > "Well, the consultant came in and patched our server and rebooted it. > Having established that--unbelievably--the problem as reported was true, and repeatable As far as problems go, this is an easy one to solve. Accurate description of the problem. Accurate reporting of what changed. Problem is consistently repeatable. Compared to a problem that doesn’t reliably reproduce and for which the person reporting it claims nothing changed, this one is child’s play. But it’s still amusing to read every time. I had something similar occur in the early 2000s on a patch release of Solaris 2.6 (I think) where the sleep call was broken and would always return almost instantly. This caused all sorts of weird behaviors on the running system. I also recall the first time I ran into an issue with MTU on a dedicated frame relay link we had to admin our web farm in the late nineties. One day a developer reported they could login to our bastion but when they ran “ls -l” in a big enough directory their ssh connection would hang. It turned out the connection would hang whenever a packet was generated near the MTU and we eventually tracked it down to an issue with the frame relay connection. We played with MTUs until we found out what worked. It then took a while to convince our provider what was going on but they eventually replaced a line card on the far end of the connection which allowed us to re-raise the MTU to 1500. Another fun problem I had was an email to SMS gateway I wrote for myself that worked by posting to a Verizon web form. I developed it on a Mac (probably 2002 or so) where it worked fine but when I deployed it to my Linux box on my same home network, the script couldn’t connect to Verizon’s site. It turned out the Linux box was a setting a flag on the TCP connection (ECN I think) that was tripping up Verizon’s web firewall. The work-around was disabling ECN on the Linux box.
分享了一个同样离奇的案例：潮汐抬高军舰导致其雷达干扰服务器。
类似的主题：我记得读过一篇关于某服务器的文章，它每隔几周就神秘崩溃。最终查明，崩溃总发生在新月或满月时——由此引发的大潮让停泊在附近港口的一艘战列舰升高到刚好使其强大雷达干扰到服务器的程度。
PhilRodgers查看英文原文
On a similar theme, I remember reading a story about a server that would crash mysteriously every couple of weeks. They eventually worked out that this happened whenever there was a new moon or a full moon, and the resulting high tide caused a battleship moored in a nearby harbour to rise just high enough that its powerful radar would interfere with the server.
指出这是 HN 的经典保留节目，像 Reddit 的 SR-71 故事一样经久流传。
这个 500 英里邮件的故事堪称 Hacker News 版的 Reddit SR-71 空中测速故事，因为人人都爱它，所以一再被翻出来。
curtis查看英文原文
The 500-mile email story seems to be the Hacker News equivalent to Reddit's SR-71 speed check story [1]. It keeps coming back again and again because everybody loves it. [1] https://www.reddit.com/r/SR71/comments/2dpmw7/the_sr71_speed_check_story/ (and many others, too numerous to reference)
补充技术细节：光纤中信号约以 0.7 倍光速传播，但故事在叙述精度上依然站得住脚。
有趣的故事，以前没听过。顺便说一句，信息在普通网络设备（如光纤）中大约以 70% 光速传播，这也是高频交易公司改用空中微波链路来省下几纳秒的原因。不过就故事讲述的精度而言，这个说法仍然成立。
yoav_hollander查看英文原文
Fun story - never heard it before. BTW, I think information travels over "normal" networking gear (e.g. fiber optics) at about 70% of the speed of light (which is why high-frequency trading tends to move to over-the-air microwave networking to shave a few nanoseconds - see [1]). But I guess the story still works, at the resolution it is told. [1] https://en.wikipedia.org/wiki/High-frequency_trading
历次讨论
同类还值得读
TTY 揭秘（2008）
The TTY demystified (2008)
经典文章深入剖析了 Unix/Linux 中 TTY 子系统的工作原理，包括线路规程、终端驱动、信号与控制字符等机制。
系统与基础设施上首页 11 次 · 2009–2025linusakesson.net编辑精选为什么 GNU grep 这么快
Why GNU grep is Fast
FreeBSD 邮件列表上一篇广为流传的帖子，解释 GNU grep 为什么快：核心在于 Boyer-Moore 字符串搜索算法配合精心优化的内部循环和 I/O，让程序在搜索时“…
系统与基础设施上首页 9 次 · 2010–2022lists.freebsd.orgXplain：为普通人讲解 X11
Xplain – Explaining X11 for the rest of us
《Xplain》是作者（HN 用户 Jasper_）写的一系列 X11 长文，用他在浏览器中重建的 X11 绘图模型做交互演示，讲解 X11 的绘图模型与窗口系统设计。
系统与基础设施上首页 6 次 · 2013–2020magcius.github.io编辑精选旋风教程：为 Linux 创建极小 ELF 可执行文件（1999）
A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux (1999)
breadbox 写于 1999 年的经典教程，主题是如何为 Linux 手工构造并裁剪出体积极小的 ELF 可执行文件。
系统与基础设施上首页 6 次 · 2007–2025muppetlabs.comPostgreSQL 内部原理
The internals of PostgreSQL
《The Internals of PostgreSQL》是一本免费在线书籍，系统讲解 PostgreSQL 的内部实现，包括查询处理、并发控制、WAL、缓冲区管理等核心机制。
系统与基础设施上首页 5 次 · 2017–2025interdb.jp编辑精选