Polecenie restartu Linux: reboot, shutdown -r now, systemctl

Polecenie restartu w Linuksie: reboot, shutdown -r now i systemctl reboot

W każdej współczesnej dystrybucji trzy poniższe polecenia restartują maszynę dokładnie w ten sam sposób. Uruchom jedno z nich jako root lub przez sudo; przez SSH konto bez uprawnień otrzyma komunikat Failed to reboot system via logind: Interactive authentication required.

sudo reboot
sudo shutdown -r now
sudo systemctl reboot

To nie są trzy różne implementacje. W dystrybucjach z systemd /sbin/reboot, /sbin/shutdown, /sbin/halt i /sbin/poweroff to dowiązania symboliczne do systemctl, które sprawdza, pod jaką nazwą zostało wywołane, i przełącza się w odpowiedni tryb zgodności; ls -l $(which reboot) pokazuje to dowiązanie. Niezależnie od wpisanej formy systemd uruchamia reboot.target, zatrzymuje wszystkie jednostki w odwrotnej kolejności zależności, odmontowuje systemy plików i prosi jądro o restart. Przez SSH połączenie zrywa się w ciągu sekundy lub dwóch; jak długo maszyna pozostanie niedostępna, zależy od jądra, ewentualnego sprawdzania systemu plików oraz od ścieżki rozruchu u dostawcy, więc daj jej minutę, zanim uznasz, że coś poszło nie tak.

Wyłączanie: shutdown -h now, poweroff, halt i przestarzałe init 6

Aby wyłączyć maszynę, wystarczy dowolne z tych poleceń:

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

W systemd -h oznacza "zatrzymaj lub wyłącz zasilanie, zależnie od domyślnego ustawienia", a domyślnie jest to wyłączenie zasilania, więc shutdown -h now i shutdown -P now są identyczne. Poleceniem, które zaskakuje użytkowników, jest samo halt: zatrzymuje system operacyjny, ale nigdy nie wysyła żądania wyłączenia zasilania, więc maszyna wirtualna stoi na komunikacie System halted, nadal zaalokowana i nadal rozliczana, dopóki nie zatrzymasz jej z panelu. Użyj zamiast tego halt -p, poweroff albo shutdown -h now.

Formy z SysV nadal działają, ponieważ systemd mapuje poziomy uruchomienia na cele: init 6 i telinit 6 odpowiadają reboot.target, a init 0 odpowiada poweroff.target. W starym skrypcie są nieszkodliwe, ale nie dają komunikatu wall, harmonogramu ani wpisu w dzienniku, więc nie ma powodu, by wpisywać je ręcznie.

Planowanie restartu, anulowanie go i ostrzeganie zalogowanych użytkowników

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

Czas może mieć postać now, +m dla m minut od teraz albo hh:mm w formacie 24-godzinnym (godzina, która dziś już minęła, oznacza jutro). Bez podania czasu shutdown przyjmuje +1: samo sudo shutdown wyłącza maszynę po sześćdziesięciu sekundach. Wszystko po czasie jest rozsyłane jako komunikat wall do każdego zalogowanego terminala, a logind powtarza ostrzeżenie w miarę zbliżania się terminu; --no-wall wycisza je, a shutdown -k wysyła ostrzeżenie, nie planując niczego. Pięć minut przed terminem logind tworzy /run/nologin i od tej chwili nowe logowania są odrzucane.

shutdown -c anuluje oczekującą operację, usuwa /run/nologin i informuje zalogowanych użytkowników, że wyłączenie zostało anulowane. Aby sprawdzić, czy jakieś oczekuje, poszukaj pliku /run/systemd/shutdown/scheduled: istnieje tylko wtedy, gdy wyłączenie jest w kolejce, i zapisuje tryb oraz docelowy czas. Nowsze wydania systemd akceptują też systemctl reboot --when=+10m wraz z --when=show i --when=cancel (sprawdź systemctl --help; starsze wydania tego nie mają).

Co dzieje się z usługami i sesjami SSH podczas restartu

Gdy zostaje zażądany reboot.target, systemd zatrzymuje wszystko, co jest z nim w konflikcie, czyli praktycznie każdą jednostkę. Usługi zatrzymują się w odwrotnej kolejności zależności: każda uruchamia swoje ExecStop albo otrzymuje SIGTERM, a jeśli nie zakończy się po czasie TimeoutStopSec (domyślnie 90 sekund, z DefaultTimeoutStopSec= w /etc/systemd/system.conf), dostaje SIGKILL. Ten limit czasu to odliczanie A stop job is running for ... widoczne na konsoli; zwykle winowajcą jest demon ignorujący SIGTERM albo baza danych, która nadal zapisuje dane. Następnie systemy plików są odmontowywane lub przemontowywane tylko do odczytu, a jądro restartuje maszynę. Nie musisz wcześniej uruchamiać sync.

Twoja sesja SSH nie jest traktowana wyjątkowo. ssh.service zatrzymuje się, zakres obejmujący twoje logowanie dostaje SIGTERM, powłoka kończy pracę, a klient wypisuje Connection to 203.0.113.10 closed by remote host. Serwer tmux lub screen chroni przed zerwanym połączeniem, ale nie przed restartem: wszystko, co działa w środku, również znika.

O tym, co wróci, decyduje włączenie jednostki, a nie to, co działało. Jednostki oznaczone jako enabled startują ponownie; cokolwiek uruchomiono ręcznie przez systemctl start, proces nohup czy kontener Dockera bez polityki restartu nie wróci. Uruchom systemctl list-unit-files --state=enabled przed i systemctl --failed po restarcie; poradnik o wyświetlaniu i filtrowaniu usług za pomocą systemctl wyjaśnia, jak czytać oba.

Bezpieczny restart VPS: lista kontrolna przed startem

Na VPS nie ma fizycznego dostępu, więc restart, po którym maszyna nie wraca, oznacza objazd przez konsolę dostawcy. Pięć kontroli, łącznie poniżej minuty, zapobiega niemal każdemu takiemu objazdowi.

1. Potwierdź, że restart jest naprawdę potrzebny

Nie każda aktualizacja go wymaga. W Ubuntu plik /var/run/reboot-required istnieje, gdy jakiś pakiet zażądał restartu, a /var/run/reboot-required.pkgs go nazywa; needrestart w Debianie i Ubuntu oraz needs-restarting -r z dnf-utils w rodzinie RHEL robią to samo gdzie indziej. Nowe jądro, glibc czy systemd uzasadniają restart; załatany nginx wymaga tylko systemctl restart nginx. Zainstaluj najpierw oczekujące aktualizacje, żeby zrestartować raz, a nie dwa razy; przewodnik o aktualizacji Ubuntu z wiersza poleceń omawia sekwencję apt i flagę reboot-required.

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

2. Upewnij się, że nic nie jest w trakcie zapisu

Przerwanie menedżera pakietów to najkrótsza droga do w połowie skonfigurowanego systemu, a kopia zapasowa przerwana w połowie to plik, który później weźmiesz za dobrą kopię. Poszukaj takich procesów i sprawdź, kto jeszcze jest zalogowany:

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

3. Zweryfikuj konfigurację, która musi przetrwać rozruch

Trzy pliki potrafią zmienić rutynowy restart w utratę dostępu. Błąd składni w sshd_config oznacza, że sshd się nie uruchomi i nie wrócisz na maszynę: sudo sshd -t nic nie wypisuje, gdy plik jest poprawny, a jeśli niedawno utwardzałeś demona SSH, uruchom to teraz. Wpis w /etc/fstab dotyczący urządzenia, które już nie istnieje, wrzuca rozruch w tryb awaryjny, o ile nie ma opcji nofail; sudo findmnt --verify wychwytuje większość takich przypadków. Zapełniony /boot może zostawić w połowie zainstalowane jądro, więc sprawdź wolne miejsce. Reguły zapory zapisane bezpośrednio przez iptables lub nft i nigdy niezapisane trwale znikają po restarcie; reguły UFW i firewalld pozostają.

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

4. Zrób punkt odniesienia

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

5. Zrestartuj, a potem zweryfikuj

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

Zgodne uname -r, czyste systemctl --failed i pusty diff oznaczają, że restart spełnił swoje zadanie.

Gdy restart się zawiesza: wymuszanie go i kiedy zamiast tego użyć konsoli dostawcy

Jeśli reboot kończy działanie, ale maszyna nigdy się nie wyłącza, zablokowane jest jakieś zadanie zatrzymania; systemctl list-jobs pokazuje które. systemctl reboot --force pomija uporządkowane zatrzymywanie jednostek: procesy są zabijane od razu, ale systemy plików nadal są odmontowywane, więc jest to gwałtowne, choć w miarę bezpieczne. --force --force restartuje natychmiast, nie odmontowując niczego, i może spowodować utratę danych; traktuj to jak wyrwanie wtyczki. Interfejs SysRq jądra to ostateczność, gdy sam systemd już nie odpowiada. Zapis do /proc/sysrq-trigger jest dla roota zawsze dozwolony, niezależnie od wartości sysctl kernel.sysrq, ale przekierowanie musi działać jako root, więc użyj powłoki roota albo 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

Sięgnij po panel lub konsolę dostawcy, gdy system gościa nie potrafi już sobie pomóc: SSH niedostępne po zmianie sieci lub zapory, jądro wpadające w panikę przy rozruchu, znak zachęty trybu awaryjnego po błędnym wpisie w fstab, zapomniane hasło roota. Reboot lub Shutdown w panelu zwykle wysyła zdarzenie zasilania ACPI, które gość obsługuje przez logind (HandlePowerKey= w logind.conf), więc usługi wciąż zatrzymują się czysto. Reset, Force stop lub Power cycle odcina wirtualne zasilanie bez ostrzeżenia: dziennik systemu plików odtworzy się przy następnym rozruchu, ale wszystko niezapisane przepada. Konsola VNC lub szeregowa pozwala obejrzeć GRUB-a, komunikaty jądra i powłokę awaryjną, których SSH nigdy ci nie pokaże.

Sprawdzanie czasu działania i ostatniego restartu maszyny

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 i who -b wypisują czas rozruchu wprost. last -x czyta /var/log/wtmp i wypisuje zarówno wpisy reboot, jak i shutdown: wiersz reboot bez poprzedzającego go wiersza shutdown oznacza, że maszyna wyłączyła się nieczysto (panika jądra albo twardy reset). journalctl --list-boots numeruje każdy rozruch znany dziennikowi, gdzie 0 to bieżący, a -1 poprzedni; journalctl -b -1 -e pokazuje wtedy ostatnie wiersze przed poprzednim wyłączeniem, gdzie ślad zostawia przekroczenie limitu zadania zatrzymania albo zabicie procesu z powodu braku pamięci. Jeśli wypisany jest tylko bieżący rozruch, dziennik jest ulotny: utwórz /var/log/journal i zrestartuj systemd-journald.

Każde powyższe polecenie opiera się na jednym założeniu: że gdy system gościa nie chce wrócić, nadal możesz się do niego dostać. VPS z Linuksem na KVM i dostępem do konsoli daje dokładnie to: prawdziwą maszynę wirtualną z własnym jądrem, dedykowanym CPU i RAM, pełnym rootem oraz konsolą na dni, gdy SSH nie wchodzi w grę. rdp.monster dostarcza ją około 10 sekund po potwierdzeniu płatności, z nielimitowanym transferem (fair-use), bez KYC, z płatnością kartą i kryptowalutami, od $8.99/miesiąc.