系统与基础设施lwn.net
Crash-only 软件：不止表面所见（2006）
Crash-only software: More than meets the eye (2006)
2014 — 2024，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇 LWN 文章介绍了 Candea 和 Fox 提出的 crash-only software 理念：系统只有一种停止方式——崩溃，只有一种启动方式——恢复。通过把崩溃恢复当作一等公民、取消优雅关闭路径，系统代码更少、重启更快、也更可靠。文章多次登上 HN 首页，被视为分布式系统设计的经典参考。
为什么经久不衰：它把'let it crash'从口号变成可操作的设计原则，在微服务和容错系统盛行的今天依然直接适用。
HN 评论精选
实践者总结 crash-only 设计的具体做法与利弊
因此我通常把所有服务和系统都做成 crash-only：使用原子文件移动、以追加方式打开文件、用 kill -9 停止服务等。要做到 crash-only，往往得深入到底层系统调用。目前观察到的一些效果：重启更快；代码更少（不用同时处理优雅关闭和脏关闭）；恢复/清理代码通常移到启动阶段而非关闭阶段；外部资源（共享内存、IPC 队列等）可能需要由监督进程管理；大量 localhost socket 操作可能耗尽临时端口；还要仔细考虑所用数据库是否支持 crash-only 运行。
rdtsc查看英文原文
> he resulting system is often more robust and reliable because crash recovery is a first-class citizen in the development process, rather than an afterthought, Because of that I usually make all my services and systems crash only. End up using things like use atomic file moves, open files with append-only, use kill -9 to stop services and so on. To make your system crash-onl,y you have to go down the base system calls. Some observed effects so far (many are covered in the article): * Faster restarts (if your regular operation involves restarting lots of processes). * Less code (don't have to handle both the clean shutdown and dirty shutdown). * Recovery/cleanup code if it is needed, is often ends up moved to startup instead of shutdown (you might have to recover corrupt files when you start up again. For example re-truncate the files to a known offset based on some index). * Something else might need to manage external resources (OS IPC recources, shared memory, IPC message queues etc). This could be a supervisor process. * If you do a lot of socket operations on localhost, your sockets could get stuck in TIME_WAIT state and you'll eventually run out of ephemeral ports if you do a lot of restarts (say during testing). SIGTERM signals often are caught and processes (libraries) perform a cleaner shutdown. * Think very well about the database you use and see if it can can support crash only operation. Some do some don't ( I won't name any names here ).
推荐论文第 3 节，强调用专门状态存储让服务无状态化
Crash-only software 是个很棒的概念，这篇文章是很好的总结。如果只读 Candea 和 Fox 论文的一节，我推荐第 3 节'Crash-Only Software 的属性'。我最喜欢的一条原则是'所有重要的非易失状态都由专门的状态存储管理'——既容忍崩溃又要保存状态非常难，把状态问题交给专门的状态存储，让许多服务变成无状态，容忍崩溃就容易多了。
mjb查看英文原文
Crash-only software is a great concept, and this article is a very interesting summary of what it is (and what it's not). If you read only one section of Candea and Fox's paper, I would recommend section 3 "Properties of Crash-Only Software". It lays out some basic properties of proper crash-only software, which work as guidelines even for software that doesn't go all the way to the crash-only ideal. My favorite one of the principles is "All important non-volatile state is managed by dedicated state stores". Being both crash-only (or even just tolerating crashes) and keeping state is a very difficult combination, and you don't want every one of your services needing to solve that problem over and over. Dedicated state stores let you hand this problem off, which turns many systems stateless (or at least without hard state). Tolerating crashes in soft-state-only services is much easier, perhaps even trivial if you follow the other rules. I wrote a blog post about this paper a while back (http://brooker.co.za/blog/2012/01/22/crash-only.html), if anybody is interested.
列举实现 crash-only 软件的具体技术手段
感觉这些讨论对'如何写 crash-only 软件'挖得不够深。可选方案有：1. 在副作用前写预写日志，或让副作用幂等；2. 双写磁盘防止撕裂写；3. 校验和避免基于坏数据做错误决策；4. 冗余/反熵等分布式模式，降低对单进程崩溃的担忧；5. 发现坏数据时的自愈模式。还有人想到别的吗？
hderms查看英文原文
I feel like people don't go deep enough into how to write 'crash only software' in these discussions. Like what are the options? 1. write ahead log before you do side effects/idempotent side effects 2. double writes to disk to prevent torn writes 3. checksums to make sure we don't make bad decisions based on bad data 4. redundancy/anti-entropy/other distributed system patterns which attempt to obviate the need to be overly concerned with a single process crashing 5. self-healing patterns when bad data is found anyone have any other ideas?
推荐 Erlang 之父的论文作为该理念的必读延伸
按惯例，谈'let it crash'或 crash-only software 时，Joe Armstrong 2003 年的博士论文《在软件错误存在的情况下构建可靠的分布式系统》是必读材料，4.3-4.4 节专门讲'let it crash'。
bobnamob查看英文原文
As is tradition when talking about "let it crash" or "crash-only software", Joe Armstrong's 2003 thesis "Making reliable distributed systems in the presence of software errors" [0] is required reading. Sections 4.3-4.4 cover "let it crash". [0]: https://erlang.org/download/armstrong_thesis_2003.pdf
历次讨论
同类还值得读
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编辑精选