Linux herunterfahren und neu starten: die Befehle shutdown, reboot und systemctl

Kurz gesagt: Linux herunterfahren geht per Befehl mit sudo shutdown -h now (oder sudo poweroff), neu starten mit sudo reboot. sudo shutdown -r now ist der ausdrückliche Weg, über den Befehl shutdown neu zu starten statt über das eigenständige Programm reboot. Alle brauchen root-Rechte, als normaler Benutzer setzt du also sudo davor. Jeder Befehl und jede Option auf dieser Seite ist mit den systemd-Manpages shutdown(8) und reboot(8) auf Debian 12 (systemd 252) abgeglichen; auf systemd setzen aktuelles Debian und Ubuntu gleichermaßen.

sudo reboot          # jetzt neu starten
sudo shutdown -h now  # jetzt herunterfahren und ausschalten
sudo poweroff         # dasselbe, direkt

Der Befehl shutdown: anhalten, ausschalten oder neu starten, auch verzögert

shutdown ist der eine Befehl, der alle drei Aktionen kann, und der einzige der Gruppe, der eine Zeitangabe und eine Warnmeldung an angemeldete Benutzer annimmt:

shutdown [OPTIONEN] [ZEIT] [WALL-MELDUNG]

now ist die Kurzform für +0. Lässt du die Zeitangabe ganz weg, gilt +1 (eine Minute ab jetzt, nicht sofort), und das erklärt meist, warum sudo shutdown allein einen Moment lang nichts zu tun scheint. Eine Wall-Meldung geht nur zusammen mit einer Zeitangabe. Mit Zeitangabe legt shutdown außerdem fünf Minuten vor dem Herunterfahren die Datei /run/nologin an, die in diesem Fenster neue Logins sperrt. shutdown -c funktioniert nur, solange ein geplanter Zeitpunkt noch aussteht: Ist der Countdown bei null angekommen, gibt es nichts mehr abzubrechen.

reboot, halt und poweroff: die direkten Befehle

Auf einem systemd-System sind diese drei praktisch dasselbe Programm unter verschiedenen Namen, und jedes tut standardmäßig, was sein Name sagt. --reboot und --halt erzwingen ihre Aktion unter jedem der drei Namen; -p (--poweroff) wirkt bei halt und poweroff, reboot ignoriert es. Zwischen poweroff und halt gibt es einen Unterschied: halt hält das System an, kann die Hardware aber eingeschaltet lassen, während poweroff wirklich den Strom abschaltet. halt -p schaltet also aus, bei poweroff ist -p ohnehin gemeint.

sudo reboot
sudo poweroff
sudo halt

systemctl reboot, poweroff und halt

systemctl bietet dieselben drei Aktionen, und sie sind es, die unter der Haube tatsächlich laufen, auch wenn du die kürzeren Befehle oben tippst: reboot, poweroff und shutdown -r now bitten am Ende alle systemd, dieselbe Arbeit zu erledigen.

sudo systemctl reboot
sudo systemctl poweroff
sudo systemctl halt

Alle drei arbeiten asynchron: Der Befehl kehrt zurück, sobald die Aktion eingereiht ist, bevor die Maschine tatsächlich heruntergefahren ist. In einer interaktiven SSH-Sitzung spielt das selten eine Rolle, weil die Verbindung ohnehin abreißt, wohl aber, wenn ein Skript den Exit-Code prüft und ihn als „die Maschine ist jetzt aus“ versteht. --force überspringt das geordnete Stoppen der laufenden Dienste; doppelt angegeben, umgeht es den Dienstmanager ganz und spricht direkt mit dem Kernel. Das ist für den Fall gedacht, dass systemd selbst abgestürzt ist, nicht für den Alltag.

Welchen Befehl sollte ich nehmen?

• Sofort, ohne Extras: sudo reboot oder sudo poweroff. Am kürzesten zu tippen, gleiches Ergebnis.
• Mit Verzögerung oder mit Vorwarnung an andere angemeldete Benutzer: shutdown, der einzige Befehl der Gruppe, der dafür gebaut ist.
• In einem Skript oder einem Automatisierungswerkzeug: systemctl reboot oder systemctl poweroff sagen am deutlichsten, worum sie systemd bitten, und lesen sich auch Monate später in einem Playbook oder Runbook eindeutig.

Nach einem Neustart, den du nicht erwartet hast

Ist der Server von selbst neu gestartet, ohne dass du es veranlasst hast, behandelt VPS startet ständig neu (engl.) die eigentlichen Ursachen: ein OOM-Kill, eine Kernel-Panic, ein Watchdog, ein geplanter shutdown, den ein Skript oder ein vergessener Cronjob hinterlassen hat. last reboot (liest /var/log/wtmp) und journalctl --list-boots sind die ersten beiden Befehle, um zu sehen, wann genau jeder frühere Boot stattfand, bevor du der Ursache weiter nachgehst.

Neustart als Teil einer größeren Aufgabe

Ein geplanter Neustart ist auch ein ganz normaler Schritt mitten in einem Versionsupgrade an Ort und Stelle. Anders als ein spontaner Neustart auf einem sonst ruhigen Server gehört er dort an eine bestimmte Stelle, und wer ihn auslässt, handelt sich echte Probleme ein. Wo genau er in den Ablauf gehört und warum, zeigt Debian 12 auf 13 upgraden (engl.).

Häufige Fragen