Comando riavvio Linux: reboot, shutdown -r now, systemctl

Il comando di riavvio di Linux: reboot, shutdown -r now e systemctl reboot

Su qualsiasi distribuzione attuale i tre comandi seguenti riavviano la macchina esattamente allo stesso modo. Eseguine uno come root o tramite sudo; via SSH un account senza privilegi ottiene Failed to reboot system via logind: Interactive authentication required.

sudo reboot
sudo shutdown -r now
sudo systemctl reboot

Non si tratta di tre implementazioni diverse. Sulle distribuzioni con systemd, /sbin/reboot, /sbin/shutdown, /sbin/halt e /sbin/poweroff sono link simbolici a systemctl, che verifica il nome con cui è stato invocato e passa alla modalità di compatibilità corrispondente; ls -l $(which reboot) mostra il link. Qualunque forma tu digiti, systemd avvia reboot.target, arresta ogni unità in ordine inverso di dipendenza, smonta i filesystem e chiede al kernel di riavviare. Via SSH la connessione cade entro un secondo o due; quanto resta assente la macchina dipende dal kernel, da un eventuale controllo del filesystem e dal percorso di avvio del provider, quindi concedi un minuto prima di sospettare un problema.

Spegnimento: shutdown -h now, poweroff, halt e il vecchio init 6

Per spegnere la macchina, va bene uno qualsiasi di questi:

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

Con systemd, -h significa «arresta o spegni, a seconda del comportamento predefinito», e il predefinito è lo spegnimento, quindi shutdown -h now e shutdown -P now sono identici. Il comando che trae in inganno è il semplice halt: arresta il sistema operativo ma non invia mai la richiesta di spegnimento, così una macchina virtuale resta ferma su System halted, ancora allocata e ancora fatturata, finché non la fermi dal pannello. Usa invece halt -p, poweroff o shutdown -h now.

Le forme SysV funzionano ancora perché systemd mappa i runlevel sui target: init 6 e telinit 6 corrispondono a reboot.target, init 0 a poweroff.target. Sono innocue in un vecchio script, ma non offrono né messaggio wall, né pianificazione, né traccia nel journal, quindi non c'è motivo di digitarle a mano.

Pianificare un riavvio, annullarlo e avvisare gli utenti collegati

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

L'orario può essere now, +m per m minuti da adesso, oppure hh:mm in formato 24 ore (un orario già passato oggi indica domani). Senza alcun orario, shutdown assume +1: un semplice sudo shutdown spegne la macchina in sessanta secondi. Tutto ciò che segue l'orario viene trasmesso come messaggio wall a ogni terminale collegato, e logind ripete l'avviso all'avvicinarsi della scadenza; --no-wall lo silenzia e shutdown -k invia l'avviso senza pianificare nulla. Cinque minuti prima della scadenza logind crea /run/nologin e da quel momento i nuovi accessi vengono rifiutati.

shutdown -c annulla l'operazione in sospeso, rimuove /run/nologin e comunica agli utenti collegati che lo spegnimento è stato annullato. Per verificare se ce n'è uno in attesa, cerca /run/systemd/shutdown/scheduled: esiste solo mentre uno spegnimento è in coda e registra la modalità e l'orario previsto. Le versioni recenti di systemd accettano anche systemctl reboot --when=+10m, con --when=show e --when=cancel (verifica con systemctl --help; le versioni più vecchie non lo supportano).

Cosa succede a servizi e sessioni SSH durante un riavvio

Quando viene richiesto reboot.target, systemd arresta tutto ciò che è in conflitto con esso, ovvero quasi ogni unità. I servizi si fermano in ordine inverso di dipendenza: ciascuno esegue il proprio ExecStop o riceve SIGTERM e, se non è uscito dopo TimeoutStopSec (90 secondi per impostazione predefinita, da DefaultTimeoutStopSec= in /etc/systemd/system.conf), riceve SIGKILL. Quel timeout è il conto alla rovescia A stop job is running for ... che si vede sulla console; di solito si tratta di un daemon che ignora SIGTERM o di un database che sta ancora scrivendo. I filesystem vengono poi smontati o rimontati in sola lettura e il kernel riavvia. Non serve eseguire sync prima.

La tua sessione SSH non gode di alcun trattamento speciale. ssh.service si arresta, lo scope che contiene il tuo login riceve SIGTERM, la tua shell muore e il client stampa Connection to 203.0.113.10 closed by remote host. Un server tmux o screen ti protegge da una connessione caduta, non da un riavvio: anche ciò che gira al suo interno sparisce.

Ciò che torna su è deciso dall'abilitazione, non da ciò che era in esecuzione. Le unità contrassegnate come enabled ripartono; tutto ciò che è stato avviato a mano con systemctl start, un processo nohup o un container Docker senza restart policy no. Esegui systemctl list-unit-files --state=enabled prima e systemctl --failed dopo; la guida su come elencare e filtrare i servizi con systemctl spiega come leggere entrambi.

Riavviare un VPS in sicurezza: la checklist preliminare

Su un VPS non c'è accesso fisico, quindi un riavvio che non ritorna significa un passaggio dalla console del provider. Cinque controlli, meno di un minuto in totale, evitano quasi ogni deviazione del genere.

1. Verifica che il riavvio serva davvero

Non tutti gli aggiornamenti lo richiedono. Su Ubuntu, /var/run/reboot-required esiste quando un pacchetto ha richiesto un riavvio e /var/run/reboot-required.pkgs ne indica il nome; needrestart su Debian e Ubuntu, e needs-restarting -r da dnf-utils sulla famiglia RHEL, fanno lo stesso controllo altrove. Un nuovo kernel, glibc o systemd giustificano un riavvio; un nginx aggiornato richiede solo systemctl restart nginx. Installa prima gli aggiornamenti in sospeso, così riavvii una volta sola e non due; la guida su come aggiornare Ubuntu da riga di comando illustra la sequenza apt e il 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. Assicurati che non ci siano scritture in corso

Interrompere un gestore di pacchetti è la via più rapida verso un sistema configurato a metà, e un backup interrotto a metà è un file che in seguito scambierai per una copia valida. Cerca quei processi e guarda chi altro è collegato:

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

3. Convalida le configurazioni che devono sopravvivere al boot

Tre file trasformano un riavvio di routine in un blocco totale. Un errore di sintassi in sshd_config significa che sshd non si avvierà e non potrai rientrare: sudo sshd -t non stampa nulla quando il file è valido, e se hai da poco irrobustito il daemon SSH, eseguilo adesso. Una voce di /etc/fstab per un dispositivo che non esiste più fa cadere l'avvio in emergency mode a meno che non porti nofail; sudo findmnt --verify intercetta buona parte di questi casi. Un /boot pieno può lasciare un kernel installato a metà, quindi controllane lo spazio libero. Le regole di firewall scritte direttamente con iptables o nft e mai salvate spariscono al riavvio; le regole UFW e firewalld invece persistono.

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

4. Registra uno stato di riferimento

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

5. Riavvia, poi verifica

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

Un uname -r coerente, un systemctl --failed pulito e un diff vuoto significano che il riavvio ha fatto il suo lavoro.

Quando il riavvio si blocca: come forzarlo e quando usare invece la console del provider

Se reboot ritorna ma la macchina non si spegne mai, c'è uno stop job bloccato; systemctl list-jobs mostra quale. systemctl reboot --force salta l'arresto ordinato delle unità: i processi vengono terminati d'autorità, ma i filesystem vengono comunque smontati, quindi è brusco ma ragionevolmente sicuro. --force --force riavvia immediatamente senza smontare nulla e può causare perdita di dati; consideralo come staccare la spina. L'interfaccia SysRq del kernel è l'ultima risorsa quando nemmeno systemd risponde più. Scrivere su /proc/sysrq-trigger è sempre consentito a root, qualunque cosa dica il sysctl kernel.sysrq, ma la redirezione deve essere eseguita come root, quindi usa una shell di root o 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

Ricorri al pannello o alla console del provider quando il guest non può più aiutarsi da solo: SSH irraggiungibile dopo una modifica di rete o firewall, un kernel che va in panic all'avvio, un prompt di emergency mode causato da una riga fstab sbagliata, una password di root dimenticata. Reboot o Shutdown in un pannello inviano normalmente un evento ACPI che il guest gestisce tramite logind (HandlePowerKey= in logind.conf), quindi i servizi si fermano comunque in modo pulito. Reset, Force stop o Power cycle tagliano l'alimentazione virtuale senza preavviso: il journal del filesystem viene riprodotto al boot successivo, ma tutto ciò che non era stato scritto va perso. La console VNC o seriale è ciò che ti permette di vedere GRUB, i messaggi del kernel e la shell di emergenza che SSH non ti mostrerà mai.

Controllare l'uptime e l'ultimo riavvio della macchina

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 e who -b stampano direttamente l'orario di avvio. last -x legge /var/log/wtmp ed elenca sia i record reboot sia quelli shutdown: una riga reboot senza una riga shutdown prima di essa significa che la macchina si è spenta in modo non pulito (un panic o un reset forzato). journalctl --list-boots numera ogni avvio noto al journal, dove 0 è quello corrente e -1 il precedente; journalctl -b -1 -e mostra poi le ultime righe prima dello spegnimento precedente, dove un timeout di uno stop job o un out-of-memory kill lasciano traccia. Se compare solo l'avvio corrente, il journal è volatile: crea /var/log/journal e riavvia systemd-journald.

Ogni comando descritto sopra si basa su un presupposto: che quando il guest non torna su, tu possa comunque raggiungerlo. Un VPS Linux KVM con accesso alla console ti dà esattamente questo, una vera macchina virtuale con kernel proprio, CPU e RAM dedicate, root completo e una console per i giorni in cui SSH non è un'opzione. rdp.monster ne consegna uno circa 10 secondi dopo la conferma del pagamento, con banda illimitata (fair-use), senza KYC, carte e criptovalute accettate, da $8.99/mese.