Crash-only software was described in a nice paper in the 9th Workshop on Hot Topics in Operating Systems (HotOS-IX), May 2003; 

	 :	Crash-only programs crash safely and recover quickly. There is only one way to stop such software—by crashing it—and only one way to bring it up—by initiating recovery. Crash-only systems are built from crash-only components, and the use of transparent component-level retries hides intra-system component crashes from end users.

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.90.9585&rep=rep1&type=pdf
----
I've only seen Crash-only computing described in the paper above. There are no references in the Wiki. The idea of only having one code path for starting and one for stopping seems like a really good example of OnceAndOnlyOnce.

But:
* has anyone really tried this? (1)
* aren't "recursive microreboots" a truly horrible idea?
----
Crash only computing seems a bit similar to Erlang's "LetItCrash".

(1) I used Crash-Only design to coordinate distributed workers and manager in a continuous integration test farm at a Large Well Known Search Engine Company. Setting time-outs correctly was a tuning point for the system. - JeffreyMiller
----
I've seen transactional databases essentially run in this way. Bring it up and it only goes down on a crash, whereupon you recover from the logs. There was a procedure for a clean shutdown, but it never got used. And the clean startup only got used once.
----
Please note that allowing a system to crash may be acceptable in handling data transactions for, say, DVD rentals out of a Redbox, but this is not an acceptable behavior for, say, a medication delivery cabinet. Let's set some limits here, folk.
----
This is how the Universe is coded
----
C''''''ategoryReallyReallyBadIdea