Linux Neustart-Befehl: reboot, shutdown -r now, systemctl reboot

Der Linux-Neustart-Befehl: reboot, shutdown -r now und systemctl reboot

Auf jeder aktuellen Distribution starten die drei folgenden Befehle die Maschine auf exakt dieselbe Weise neu. Führen Sie einen davon als root oder über sudo aus; per SSH erhält ein Konto ohne Rechte die Meldung Failed to reboot system via logind: Interactive authentication required.

sudo reboot
sudo shutdown -r now
sudo systemctl reboot

Das sind nicht drei Implementierungen. Auf systemd-Distributionen sind /sbin/reboot, /sbin/shutdown, /sbin/halt und /sbin/poweroff Symlinks auf systemctl, das den Namen prüft, unter dem es aufgerufen wurde, und in den passenden Kompatibilitätsmodus wechselt; ls -l $(which reboot) zeigt den Link. Welche Schreibweise Sie auch tippen, systemd startet reboot.target, stoppt jede Unit in umgekehrter Abhängigkeitsreihenfolge, hängt die Dateisysteme aus und fordert den Kernel zum Neustart auf. Über SSH bricht die Verbindung binnen ein bis zwei Sekunden ab; wie lange die Maschine wegbleibt, hängt vom Kernel, von einer eventuellen Dateisystemprüfung und vom Boot-Pfad des Anbieters ab, rechnen Sie also mit einer Minute, bevor Sie ein Problem vermuten.

Herunterfahren: shutdown -h now, poweroff, halt und das alte init 6

Zum Ausschalten der Maschine genügt eines der beiden:

sudo shutdown -h now
sudo poweroff          # identical to: sudo systemctl poweroff

Unter systemd bedeutet -h "anhalten oder ausschalten, je nach Standard", und der Standard ist Ausschalten, weshalb shutdown -h now und shutdown -P now identisch sind. Der Befehl, der zur Falle wird, ist das nackte halt: Es hält das Betriebssystem an, sendet aber nie die Abschaltanforderung, sodass eine virtuelle Maschine bei System halted stehen bleibt, weiterhin belegt und weiterhin abgerechnet, bis Sie sie im Panel stoppen. Nutzen Sie stattdessen halt -p, poweroff oder shutdown -h now.

Die SysV-Formen funktionieren weiterhin, weil systemd Runlevel auf Targets abbildet: init 6 und telinit 6 führen zu reboot.target, init 0 zu poweroff.target. In einem alten Skript sind sie harmlos, bieten aber keine wall-Nachricht, keine Planung und keinen Journal-Eintrag, es gibt also keinen Grund, sie von Hand einzutippen.

Einen Neustart planen, abbrechen und angemeldete Benutzer warnen

sudo shutdown -r +10 "Kernel update, back in about two minutes"
sudo shutdown -r 02:30
sudo shutdown -c

Die Zeit kann now sein, +m für m Minuten ab jetzt oder hh:mm im 24-Stunden-Format (eine heute bereits vergangene Uhrzeit bedeutet morgen). Ohne jede Zeitangabe nimmt shutdown +1 an: Ein blankes sudo shutdown schaltet die Maschine in sechzig Sekunden aus. Alles nach der Zeitangabe wird als wall-Nachricht an jedes angemeldete Terminal gesendet, und logind wiederholt die Warnung, je näher der Termin rückt; --no-wall hält es still, und shutdown -k sendet die Warnung, ohne etwas zu planen. Fünf Minuten vor dem Termin legt logind /run/nologin an, und neue Anmeldungen werden ab dann abgewiesen.

shutdown -c bricht den anstehenden Vorgang ab, entfernt /run/nologin und teilt den angemeldeten Benutzern mit, dass das Herunterfahren abgebrochen wurde. Um zu prüfen, ob eines ansteht, sehen Sie nach /run/systemd/shutdown/scheduled: Die Datei existiert nur, solange ein Herunterfahren eingeplant ist, und hält Modus sowie Zielzeit fest. Neuere systemd-Versionen akzeptieren zudem systemctl reboot --when=+10m, mit --when=show und --when=cancel (prüfen Sie systemctl --help; ältere Versionen kennen das nicht).

Was während eines Neustarts mit Diensten und SSH-Sitzungen geschieht

Wird reboot.target angefordert, stoppt systemd alles, was damit in Konflikt steht, also nahezu jede Unit. Dienste werden in umgekehrter Abhängigkeitsreihenfolge beendet: Jeder führt sein ExecStop aus oder erhält SIGTERM, und wenn er nach TimeoutStopSec (standardmäßig 90 Sekunden, aus DefaultTimeoutStopSec= in /etc/systemd/system.conf) nicht beendet ist, bekommt er SIGKILL. Dieses Zeitlimit ist der auf der Konsole sichtbare Countdown A stop job is running for ...; meist ein Daemon, der SIGTERM ignoriert, oder eine Datenbank, die noch schreibt. Anschließend werden die Dateisysteme ausgehängt oder schreibgeschützt neu eingehängt, und der Kernel startet neu. Ein vorheriges sync ist nicht nötig.

Ihre SSH-Sitzung wird nicht besonders behandelt. ssh.service wird gestoppt, der Scope Ihrer Anmeldung erhält SIGTERM, Ihre Shell stirbt, und der Client gibt Connection to 203.0.113.10 closed by remote host aus. Ein tmux- oder screen-Server schützt Sie vor einer abgerissenen Verbindung, nicht vor einem Neustart: Was darin läuft, ist ebenfalls weg.

Was zurückkommt, entscheidet die Aktivierung, nicht das, was gerade lief. Als enabled markierte Units starten wieder; alles, was von Hand mit systemctl start gestartet wurde, ein nohup-Prozess oder ein Docker-Container ohne Restart-Policy jedoch nicht. Führen Sie vorher systemctl list-unit-files --state=enabled und danach systemctl --failed aus; der Leitfaden zum Auflisten und Filtern von Diensten mit systemctl erklärt, wie Sie beides lesen.

Einen VPS sicher neu starten: die Checkliste vorab

Auf einem VPS gibt es keinen physischen Zugriff, ein Neustart, der nicht zurückkommt, bedeutet also einen Umweg über die Konsole des Anbieters. Fünf Prüfungen, zusammen unter einer Minute, verhindern fast jeden solchen Umweg.

1. Prüfen, ob der Neustart wirklich nötig ist

Nicht jedes Update erfordert einen. Unter Ubuntu existiert /var/run/reboot-required, wenn ein Paket einen Neustart verlangt hat, und /var/run/reboot-required.pkgs nennt es; needrestart unter Debian und Ubuntu sowie needs-restarting -r aus dnf-utils auf der RHEL-Seite führen anderswo dieselbe Prüfung durch. Ein neuer Kernel, glibc oder systemd rechtfertigt einen Neustart; ein gepatchtes nginx braucht nur systemctl restart nginx. Installieren Sie ausstehende Updates zuerst, damit Sie einmal neu starten und nicht zweimal; die Anleitung zum Aktualisieren von Ubuntu über die Kommandozeile behandelt den apt-Ablauf und das reboot-required-Flag.

[ -f /var/run/reboot-required ] && cat /var/run/reboot-required.pkgs
uname -r; ls /boot/vmlinuz-*     # running kernel vs. newest installed

2. Sicherstellen, dass nichts mitten im Schreiben ist

Einen Paketmanager zu unterbrechen ist der schnellste Weg zu einem halb konfigurierten System, und ein auf halber Strecke abgebrochenes Backup ist eine Datei, die Sie später für eine gute Kopie halten werden. Suchen Sie nach solchen Prozessen und sehen Sie nach, wer sonst noch angemeldet ist:

pgrep -a 'apt|dpkg|dnf|yum|unattended'
pgrep -a 'rsync|mysqldump|pg_dump|restic|borg'
w

3. Die Konfiguration prüfen, die den Bootvorgang überstehen muss

Drei Dateien machen aus einem Routineneustart eine Aussperrung. Ein Syntaxfehler in sshd_config bedeutet, dass sshd nicht startet und Sie nicht wieder hineinkommen: sudo sshd -t gibt nichts aus, wenn die Datei gültig ist, und wenn Sie kürzlich den SSH-Daemon gehärtet haben, führen Sie es jetzt aus. Ein Eintrag in /etc/fstab für ein nicht mehr vorhandenes Gerät lässt den Bootvorgang im Notfallmodus enden, sofern er kein nofail trägt; sudo findmnt --verify fängt das meiste davon ab. Ein volles /boot kann einen halb installierten Kernel hinterlassen, prüfen Sie also den freien Speicherplatz. Firewall-Regeln, die direkt mit iptables oder nft geschrieben und nie gespeichert wurden, verschwinden beim Neustart; UFW- und firewalld-Regeln bleiben erhalten.

sudo sshd -t
sudo findmnt --verify
df -h / /boot

4. Eine Referenzaufnahme machen

systemctl --failed
systemctl list-units --type=service --state=running > ~/services-before.txt

5. Neu starten, dann überprüfen

sudo systemctl reboot --message="post-update reboot"
# after reconnecting:
uptime -s; systemctl --failed
systemctl list-units --type=service --state=running | diff ~/services-before.txt -

Ein passendes uname -r, ein sauberes systemctl --failed und ein leerer Diff bedeuten, dass der Neustart seine Aufgabe erfüllt hat.

Wenn der Neustart hängt: erzwingen und wann stattdessen die Anbieterkonsole hilft

Wenn reboot zurückkehrt, die Maschine aber nie herunterfährt, hängt ein Stop-Job; systemctl list-jobs zeigt, welcher. systemctl reboot --force überspringt das geordnete Beenden der Units: Prozesse werden hart beendet, die Dateisysteme werden aber weiterhin ausgehängt, es ist also abrupt und trotzdem einigermaßen sicher. --force --force startet sofort neu, ohne irgendetwas auszuhängen, und kann Daten verlieren; behandeln Sie es wie das Ziehen des Steckers. Die SysRq-Schnittstelle des Kernels ist das letzte Mittel, wenn systemd selbst nicht mehr antwortet. Das Schreiben nach /proc/sysrq-trigger ist für root immer erlaubt, unabhängig vom sysctl kernel.sysrq, aber die Umleitung muss als root laufen, verwenden Sie also eine root-Shell oder sudo sh -c:

echo s > /proc/sysrq-trigger   # sync dirty buffers
echo u > /proc/sysrq-trigger   # remount filesystems read-only
echo b > /proc/sysrq-trigger   # reboot right now

Greifen Sie zum Panel oder zur Konsole des Anbieters, wenn sich das Gastsystem nicht mehr selbst helfen kann: SSH nach einer Netzwerk- oder Firewall-Änderung nicht erreichbar, ein Kernel, der beim Booten in Panik gerät, eine Notfallmodus-Eingabeaufforderung wegen einer fehlerhaften fstab-Zeile, ein vergessenes root-Passwort. Reboot oder Shutdown im Panel senden normalerweise ein ACPI-Power-Ereignis, das der Gast über logind verarbeitet (HandlePowerKey= in logind.conf), sodass die Dienste weiterhin sauber stoppen. Reset, Force stop oder Power cycle kappen die virtuelle Stromzufuhr ohne Vorwarnung: Das Journal des Dateisystems wird beim nächsten Boot nachgefahren, aber alles Ungeschriebene ist verloren. Die VNC- oder serielle Konsole ist das, womit Sie GRUB, die Kernel-Meldungen und die Notfall-Shell sehen, die SSH Ihnen nie zeigt.

Laufzeit prüfen und feststellen, wann die Maschine zuletzt neu gestartet wurde

uptime -p                      # up 3 days, 4 hours, 12 minutes
uptime -s                      # 2026-08-31 02:31:07
who -b                         # system boot  2026-08-31 02:31
last -x reboot shutdown | head
journalctl --list-boots

uptime -s und who -b geben die Bootzeit direkt aus. last -x liest /var/log/wtmp und listet sowohl reboot- als auch shutdown-Einträge: Eine reboot-Zeile ohne vorangehende shutdown-Zeile bedeutet, dass die Maschine unsauber heruntergegangen ist (eine Panik oder ein harter Reset). journalctl --list-boots nummeriert jeden Bootvorgang, den das Journal kennt, wobei 0 der aktuelle und -1 der vorherige ist; journalctl -b -1 -e zeigt dann die letzten Zeilen vor dem vorherigen Herunterfahren, wo ein Stop-Job-Timeout oder ein Out-of-Memory-Kill seine Spur hinterlässt. Ist nur der aktuelle Bootvorgang aufgeführt, ist das Journal flüchtig: Legen Sie /var/log/journal an und starten Sie systemd-journald neu.

Jeder oben genannte Befehl beruht auf einer Annahme: dass Sie das Gastsystem noch erreichen können, wenn es sich weigert zurückzukommen. Ein KVM Linux VPS mit Konsolenzugriff bietet genau das, eine echte virtuelle Maschine mit eigenem Kernel, dediziertem CPU und RAM, vollem root-Zugriff und einer Konsole für die Tage, an denen SSH keine Option ist. rdp.monster liefert ihn etwa 10 Sekunden nach Zahlungsbestätigung, mit unbegrenzter Bandbreite (Fair Use), ohne KYC, Karten und Krypto werden akzeptiert, ab $8.99/Monat.