Es ist die banalste Geste im Umgang mit einem Computer. Man klickt auf ein Symbol, wartet ein paar Sekunden, das Bild wird schwarz. Dabei ist das Herunterfahren technisch gesehen einer der kompliziertesten Vorgänge, die ein Betriebssystem beherrschen muss, und die Art, wie die verschiedenen Systeme das lösen, unterscheidet sich stärker, als du vermutlich denkst. Bei Windows bedeutet ein Klick auf "Herunterfahren" seit über zehn Jahren gar kein Herunterfahren mehr. Bei einem iPhone laufen nach dem Ausschalten noch drei Funkchips weiter. Und unter Linux bekommst du zum Abschied gelegentlich noch die Meldung serviert, dass ein Stop-Job seit anderthalb Minuten läuft.
Ich habe mich gefragt, woher diese Prozedur eigentlich kommt. Warum kann man einen Computer nicht einfach ausschalten, so wie man eine Lampe ausschaltet? Die Antwort führt zurück in die Siebzigerjahre, zu Grossrechnern, langsamen Festplatten und einem Betriebssystem, das aus reiner Leistungsnot anfing, deine Daten erst mal nicht zu speichern.
Warum es überhaupt eine Prozedur braucht
Der Grund ist ein Trick, ohne den frühe Unix-Systeme unbenutzbar langsam gewesen wären: der Buffer Cache. Wenn ein Programm eine Datei schreibt, landet der Inhalt nicht sofort auf der Platte, sondern zunächst im Arbeitsspeicher. Das Betriebssystem sammelt diese schmutzigen Blöcke und schreibt sie später gebündelt weg. Für die Performance ist das ein Segen, für die Datenintegrität eine Zeitbombe. Wer in diesem Moment den Strom kappt, verliert nicht nur die Datei, an der er gerade gearbeitet hat, sondern potenziell die Verwaltungsstrukturen des Dateisystems gleich mit.
Die Antwort darauf war ein Kommando namens shutdown, und es ist deutlich älter, als man annehmen würde. Ausserhalb der Bell Labs tauchte es erstmals in PWB/UNIX 1.0 auf, die zugehörige Manpage trägt das Datum 31. Mai 1977. Sie beschreibt die Aufgabe in einer Klarheit, die bis heute gilt: alle laufenden Prozesse geordnet und vorsichtig beenden, alle Benutzer benachrichtigen, alle Dateisysteme aushängen. Und dann der entscheidende Satz, dass sämtliche Superblöcke aktualisiert werden müssen, bevor das System angehalten wird, um die Integrität des Dateisystems sicherzustellen. Der häufigste Fehler damals war übrigens derselbe wie heute: "device busy", ein Dateisystem liess sich nicht aushängen.
Aus dieser Zeit stammt auch ein Ritual, das sich zäh gehalten hat: sync, sync, sync. Der Grund dafür ist wunderbar profan. Das sync-Kommando rief einen Systemaufruf auf, der die schmutzigen Puffer zwar zum Schreiben markierte, aber nicht auf den Abschluss wartete. Die drei Aufrufe hintereinander erledigten nichts Zusätzliches, sie verschafften der Festplatte schlicht genug Zeit, tatsächlich fertig zu werden, bevor der Operator den Schalter umlegte. Seit Linux 1.3.20 im Jahr 1995 ist sync synchron, das Ritual damit sachlich überflüssig. Getippt wird es trotzdem weiterhin, so wie man beim Weggehen zweimal prüft, ob die Tür wirklich zu ist.
Was bei einem unsauberen Ausschalten drohte, hiess fsck, geschrieben von Ted Kowalski bei Bell Labs und 1980 auf dem V7-Addendum-Tape verteilt. Ein vollständiger Durchlauf durch alle Datenstrukturen eines Dateisystems, und je grösser die Platten wurden, desto brutaler wurde die Wartezeit. Erst Journaling entschärfte das Problem. IBM lieferte 1990 mit JFS in AIX 3.1 eines der ersten kommerziellen Beispiele, Microsoft brachte NTFS 1993 mit Windows NT 3.1 samt Log-Datei, und Linux bekam mit ext3 im November 2001 seinen Journaling-Standard. Seither ist ein unsauberes Aus meist kein Drama mehr, sondern ein Journal-Replay von wenigen Sekunden beim nächsten Mounten. Wichtig ist trotzdem die Einschränkung: Ein Journal schützt in den üblichen Modi die Metadaten, nicht zwingend deine Nutzdaten. Die halb geschriebene Datei ist trotzdem weg.
Als die Software lernte, den Stecker zu ziehen
Bis Mitte der Neunzigerjahre endete das Herunterfahren beim PC an einer physikalischen Grenze. AT-Netzteile hatten einen mechanisch rastenden Schalter direkt in der Netzleitung, Software konnte da schlicht nichts ausrichten. Erst die ATX-Spezifikation, die Intel im Juli 1995 veröffentlichte, brachte die beiden Signale, die das änderten: PS_ON, mit dem das Mainboard das Netzteil ein- und ausschalten kann, und die Standby-Schiene mit 5 Volt, die auch dann anliegt, wenn der Rechner scheinbar aus ist. Sie versorgt die Echtzeituhr und hält jene Schaltung am Leben, die auf den Einschaltknopf lauscht.
Parallel dazu entstand die Software-Seite. Intel und Microsoft veröffentlichten 1992 die erste Fassung von APM, bei der noch das BIOS das Energiemanagement kontrollierte. Im Dezember 1996 folgte ACPI von Intel, Microsoft und Toshiba, das die Kontrolle bewusst dem Betriebssystem übergab und seit 2013 vom UEFI Forum gepflegt wird. ACPI liefert bis heute das Vokabular, mit dem man über das Thema überhaupt sinnvoll reden kann. Der Zustand G2, auch S5 genannt, heisst dort "Soft Off": minimaler Stromverbrauch, kein Code läuft mehr, kein Kontext bleibt erhalten, beim nächsten Mal muss vollständig gebootet werden. Erst G3, "Mechanical Off", ist wirklich aus, und die Spezifikation beschreibt das mit einem sehr trockenen Bild als das Abschalten der Stromversorgung durch die Bewegung eines grossen roten Schalters. Wer die Kiste also wirklich stromlos haben will, muss den Stecker ziehen.
In diese Übergangszeit fällt der Bildschirm, den vermutlich jeder kennt, der die Neunziger erlebt hat: "It's now safe to turn off your computer." Raymond Chen (langjähriger Windows Entwickler) hat erklärt, warum es ihn gab. Die Leute fuhren Windows herunter und wussten dann nicht, was sie tun sollten. Der Bildschirm war die ausdrückliche Erlaubnis, jetzt den Netzschalter zu drücken. Auf Rechnern ohne Soft-Power-Fähigkeit blieb er noch bis in die Zeiten von Windows 2000 und XP übrig, danach verschwand er mit der Hardware, die ihn nötig machte.
Und noch eine Zahl aus derselben Spezifikation, die jeder kennt, ohne zu wissen woher: Die vier Sekunden, die man den Einschaltknopf gedrückt halten muss, damit die Kiste hart abschaltet, sind ACPI-definiert. Es heisst dort Power Button Override, und der Zweck ist explizit ein Notausgang für den Fall, dass das Betriebssystem auf gar nichts mehr reagiert. Das Override läuft in der Hardware, am Betriebssystem vorbei. Deshalb gibt es dabei kein sync, kein sauberes Aushängen und keine Rücksicht auf irgendetwas.
Windows fährt seit Windows 8 nicht mehr herunter
Damit sind wir bei der grössten Überraschung dieser Recherche, auch wenn sie unter Linux-Leuten seit Jahren herumgeht. Klickst du bei Windows auf "Herunterfahren", passiert seit Windows 8 standardmässig etwas anderes als das, was draufsteht. Microsoft nennt es Fast Startup oder Hybrid Shutdown. Deine Benutzersitzungen werden tatsächlich beendet und abgemeldet, Anwendungen geschlossen. Was übrig bleibt, ist die Kernel-Sitzung mitsamt Diensten und geladenen Treibern, und die wird nicht beendet, sondern in die Datei hiberfil.sys geschrieben. Beim nächsten Start lädt Windows dieses Abbild zurück, statt den Kernel neu zu initialisieren. Microsoft hat damals Verbesserungen von dreissig bis siebzig Prozent bei den Startzeiten gemessen.
Der Rechner landet dabei nicht in S5, sondern in S4, dem Ruhezustand. Microsoft schreibt das selbst in der Dokumentation zu Wake on LAN, und dort steht auch, warum WoL nach dem Herunterfahren bei vielen Leuten nicht mehr funktioniert. Für Treiberentwickler gibt es eigens eine Struktur, um die beiden Fälle zu unterscheiden: Beim Hybrid Shutdown steht als Zielzustand "Shutdown", als effektiver Zustand aber "Hibernate".
Die Konsequenzen sind alltagstauglich absurd. "Neu starten" führt einen vollständigen Boot-Zyklus durch, "Herunterfahren" nicht. Wer also ein Problem hat, muss neu starten, nicht ausschalten und wieder einschalten. Microsoft dokumentiert das ausdrücklich: Manche Windows-Updates können nur nach einem vollständigen Shutdown abgeschlossen werden, und die offizielle Empfehlung lautet, dafür "Neu starten" zu wählen.
Für uns Linux-Leute mit Dual-Boot ist die Sache noch unangenehmer. Nach einem Hybrid Shutdown bleibt die NTFS-Partition in einem Zustand zurück, den Linux zu Recht als schmutzig einstuft. Der Kernel-Treiber ntfs3 mountet sie dann nicht normal, und die Option force, die das erzwingen würde, ist in der Kernel-Dokumentation ausdrücklich als nicht empfohlen markiert. Mit ntfs-3g bekommst du stattdessen die Meldung, Windows sei im Ruhezustand und das Mounten werde verweigert. Der saubere Weg ist, Fast Startup abzuschalten, entweder mit powercfg /h off in einer administrativen Konsole oder über die Energieoptionen. Alternativ tut es einmalig auch shutdown /s /t 0, das einen vollständigen Shutdown erzwingt.
Linux macht es umständlich, aber ehrlich
Unter Linux gibt es diese Abkürzung nicht. Ein Shutdown ist ein vollständiger Abbau, und man kann ihm dabei zusehen. Systemd zieht dafür shutdown.target und umount.target heran, die im Konflikt zu allen Services beziehungsweise allen Mounts stehen, und läuft über final.target in eine der Endstationen, also systemd-poweroff.service, systemd-reboot.service oder systemd-halt.service.
Danach übernimmt eine zweite Phase, in der PID 1 durch das Programm systemd-shutdown ersetzt wird. Das versucht alle verbliebenen Dateisysteme auszuhängen oder wenigstens schreibgeschützt neu einzuhängen, schaltet die Swap-Geräte ab, löst verbliebene Loop- und Device-Mapper-Geräte auf und killt alles, was noch läuft. Ganz am Schluss folgt der Systemaufruf reboot mit dem Kommando für Power Off, dessen Magic-Wert die schöne Hexadezimalzahl 0x4321fedc ist und der laut Manpage die Meldung "Power down." ausgibt, bevor das System dem Strom Lebewohl sagt.
Die berüchtigte Meldung "A stop job is running for ..." mit dem Countdown von anderthalb Minuten erklärt sich aus einer einzigen Konfigurationsvariable: DefaultTimeoutStopSec ist auf neunzig Sekunden voreingestellt. Systemd hat der Unit ein SIGTERM geschickt, wartet die Frist ab und greift danach zu SIGKILL. Wer den Wert in /etc/systemd/system.conf herunterschraubt, verkürzt das Wartespiel, riskiert aber, dass Dienste weniger Zeit zum Aufräumen bekommen.
Ein Äquivalent zu Fast Startup gibt es nicht, aber es gibt Ansätze in eine ähnliche Richtung. Mit kexec lässt sich aus dem laufenden Kernel heraus direkt ein neuer Kernel starten, wobei die gesamte Hardware-Initialisierung durch Firmware und Bootloader entfällt. Und systemd 254 brachte im Juli 2023 den Soft Reboot, bei dem nur der Userspace neu startet: Services werden beendet, optional wird in ein neues Root-Dateisystem unter /run/nextroot gewechselt, und eine neue systemd-Instanz fährt das System wieder hoch. Firmware, Bootloader, Kernel-Initialisierung und Initrd bleiben aussen vor. Die Manpage warnt allerdings ausdrücklich davor, das Überleben von Ressourcen über diesen Wechsel hinweg allzu grosszügig zu nutzen, weil es das System fragiler macht.
macOS schaltet ab, indem es Programme erschiesst
Apple geht einen dritten Weg. Der Shutdown selbst ist vollständig und ehrlich, aber der Weg dorthin ist bemerkenswert rabiat. Seit Mac OS X 10.6 gibt es Sudden Termination, und Apple beschreibt das ohne jede Beschönigung als einen Mechanismus, der das Abmelden und Herunterfahren beschleunigt, indem er Anwendungen abschiesst, statt sie höflich um ihr Beenden zu bitten. Programme melden über einen Konfiguration an, ob sie das vertragen, und AppKit deaktiviert das automatisch in heiklen Momenten, etwa zwischen dem Setzen einer Einstellung und dem Wegschreiben der Preferences-Datei. Für Entwickler hat das eine unangenehme Folge: Bei Apps mit aktivierter Sudden Termination wird applicationWillTerminate schlicht nie aufgerufen.
Auch für Hintergrundprozesse ist Apple direkt. Beim Herunterfahren geht ein SIGTERM an alle Daemons, wenige Sekunden später folgt SIGKILL. Der loginwindow-Prozess wartet beim Abmelden gar nicht erst auf Antworten von Hintergrundprozessen, sondern killt sie unabhängig von zurückgemeldeten Fehlern. Nur Vordergrund-Apps bekommen Rücksicht, und zwar 45 Sekunden. Antwortet eine App bis dahin nicht, bricht macOS die ganze Aktion ab. Das ist die spiegelbildliche Designentscheidung zu Windows, wo dir stattdessen ein Bildschirm anbietet, das Beenden zu erzwingen.
Dass sich ein Neustart am Mac trotzdem nicht wie ein Neuanfang anfühlt, liegt an Resume, jener Funktion aus OS X Lion, die beim erneuten Anmelden alle Fenster wieder öffnet. Kombiniert mit APFS ergibt das ein System, bei dem das Herunterfahren fast unsichtbar wird. APFS verzichtet übrigens bewusst auf ein Journal und setzt stattdessen auf Copy-on-Write für Metadaten, was Apple mit dem Wegfall des doppelten Schreibaufwands begründet. Ein Zwischenzustand kann dabei gar nicht erst entstehen, es gilt entweder der alte oder der neue Stand.
Bei Apple Silicon kommt hinzu, dass die Boot-Kette eher an ein iPhone erinnert als an einen PC: Boot ROM, Low-Level Bootloader, eine vom Secure Enclave signierte lokale Sicherheitsrichtlinie, dann iBoot, das den Root-Hash des signierten Systemvolumes prüft. Keine UEFI-Phase, keine Option-ROMs. Das Ergebnis sind Startzeiten, bei denen die Frage, ob man herunterfahren soll, ihre Dringlichkeit verliert. Eine offizielle Empfehlung von Apple dazu gibt es übrigens nicht, entgegen dem, was man oft liest. Der entsprechende Support-Artikel beschreibt nur, wie man herunterfährt, und nennt Situationen, in denen es nötig ist.
Beim Smartphone ist "aus" eine Meinung
Android ist Linux, und entsprechend ähnlich sieht der Ablauf aus, nur mit deutlich strafferen Fristen. Die Klasse ShutdownThread im Framework verschickt zunächst einen Broadcast namens ACTION_SHUTDOWN und gibt den Apps dafür genau zehn Sekunden. Wer nicht antwortet, wird protokolliert und ignoriert. Interessant ist ein Detail im Quellcode: Der Broadcast trägt das Flag, dass nur zur Laufzeit registrierte Empfänger ihn bekommen. Eine App, die im Manifest deklariert, sie wolle über das Ausschalten informiert werden, bekommt schlicht nichts. Danach wird der ActivityManager heruntergefahren, ebenfalls mit zehn Sekunden, dann der PackageManager, dann die Funkmodems mit zwölf Sekunden.
Der letzte wahrnehmbare Akt ist die Vibration, standardmässig 500 Millisekunden lang, und sie kommt nur beim echten Ausschalten, nicht beim Neustart. Der Thread schläft dabei extra so lange, weil der Vibrationsmotor asynchron arbeitet und das Gerät sonst zu früh abschaltet. Das Aushängen der Dateisysteme macht das Framework dann gar nicht mehr selbst, der Kommentar im Code sagt lapidar, die restliche Arbeit erledige init. Dort bekommen die Services eine Frist von drei Sekunden auf SIGTERM, danach SIGKILL ohne Gnadenfrist, dann vold, dann sync, aushängen, nochmal sync, und schliesslich derselbe reboot-Systemaufruf, den auch dein Desktop-Linux verwendet.
Der Trick mit dem langen Drücken der Einschalttaste plus Lautstärketaste hat übrigens eine schöne technische Erklärung. Bei Qualcomm-Geräten sitzt das im Power-Management-Chip, und in den Devicetree-Bindings steht der maximale Wert für den ersten Debounce-Timer: 10256 Millisekunden. Daher die berühmten zehn Sekunden. Der Chip führt danach die konfigurierte Reset-Sequenz aus, komplett am Kernel vorbei, weshalb das auch bei einem vollständig eingefrorenen System noch funktioniert.
Bei iOS wird es dann richtig spannend, weil dort das Ausschalten zur Sicherheitsfunktion geworden ist. Der Kern ist die Data Protection: Beim Sperren verwirft das Gerät den Klassenschlüssel für die höchste Schutzklasse nach rund zehn Sekunden, beim Ausschalten sind sämtliche abgeleiteten Schlüssel weg. Genau das ist der Unterschied zwischen den beiden Zuständen, um die sich die halbe Mobilforensik dreht. Ein Gerät, das seit dem Start noch nie entsperrt wurde, gibt praktisch nichts her. Eines, das einmal entsperrt wurde, hat die Schlüssel im Speicher, auch wenn der Bildschirm gesperrt ist. Deshalb halten Ermittlungsbehörden beschlagnahmte Geräte am Strom und wach, und deshalb empfiehlt die NSA in ihren Mobile Device Best Practices ausdrücklich, das Gerät wöchentlich aus- und wieder einzuschalten.
Apple hat diese Erkenntnis inzwischen automatisiert. Seit iOS 18 gibt es den Inactivity Reboot, der das Gerät neu startet, wenn es zu lange gesperrt liegen bleibt. In iOS 18.0 lag die Frist noch bei sieben Tagen, ab 18.1 sind es 72 Stunden. Die Sicherheitsforscherin Jiska Classen hat die Funktion durch Reverse Engineering aufgedeckt, nachdem sich US-Ermittler über unerklärlich neu startende iPhones gewundert hatten. Der Timer läuft in der Secure Enclave, also genau dort, wo ein Angreifer am schlechtesten hinkommt. Angekündigt hat Apple das Ganze nie. Google ist inzwischen nachgezogen und listet einen Neustart nach 72 Stunden Sperre offiziell als Bestandteil des Advanced-Protection-Modus in Android 16.
Eine Arbeit von Classen und Kollegen an der TU Darmstadt, vorgestellt auf der ACM WiSec 2022 unter dem passenden Titel "Evil Never Sleeps", hat nachgewiesen, dass Bluetooth, NFC und Ultrabreitband beim iPhone nach dem Ausschalten weiterlaufen. Sie arbeiten in einem Low Power Mode, der von iOS unabhängig ist, und genau daraus speist sich die Fähigkeit, ein ausgeschaltetes iPhone in "Wo ist?" zu finden. Die Kehrseite haben die Forschenden gleich mitgeliefert: Die Firmware des Bluetooth-Chips ist weder signiert noch verschlüsselt, und sie konnten Schadcode darauf laden, der bei ausgeschaltetem Telefon ausgeführt wird.
Was bleibt
Das Herunterfahren wurde erfunden, weil Computer log-, aber nicht stromausfallsicher waren. Die Gründe von 1977 sind heute weitgehend entschärft, Journaling und Copy-on-Write haben den Schrecken des harten Aus genommen. Was sich stattdessen verändert hat, ist die Bedeutung des Wortes selbst. Bei Windows ist "Herunterfahren" heute ein Ruhezustand mit anderem Namen. Bei macOS ist es ein Vorgang, den das System durch Fenster-Wiederherstellung möglichst unsichtbar macht. Beim Smartphone ist es ein Softwarezustand, bei dem Funkchips weiterlaufen.
Ausgerechnet Linux, das oft als das umständliche System gilt, ist damit dasjenige, bei dem "Aus" noch aus heisst. Neunzig Sekunden Stop-Job inklusive.
