La differenza tra questi comandi per abbattere un server Linux?

Il comando "halt" esegue lo spegnimento del sistema al livello di esecuzione 0 di
del sistema.

Il comando "shutdown" esegue uno spegnimento del sistema al livello di esecuzione
1 senza il comando -ho -r.

Che dire del comando "poweroff" entra nel livello di esecuzione 0 o 1?
È questa l'unica differenza principale tra questi tre comandi?

Risposta accettata:

E ora, la risposta di sistema.

Stai usando, secondo il tag sulla tua domanda, Red Hat Enterprise Linux. Dalla versione 7, ha utilizzato systemd. Nessuna delle altre risposte è corretta per il mondo di systemd; né ci sono nemmeno alcune delle ipotesi nella tua domanda.

• Dimentica i runlevel; esistono, ma solo come spessori di compatibilità. La documentazione del sistema afferma che il concetto è "obsoleto". Se stai iniziando a imparare queste cose su un sistema operativo systemd, non iniziare da lì.
• Dimentica la pagina di manuale citata da marcelm; non proviene affatto dal set di strumenti corretto ed è una descrizione del comando di un altro set di strumenti, errato per i systemd. È quello per l'halt comando dal furgone Smoorenburg “System 5” init utilità.
• Ignora le istruzioni che /sbin/halt è un collegamento simbolico a /sbin/reboot; questo non è vero con systemd. Non esiste un reboot separato programma a tutti.
• Ignora le istruzioni che halt o reboot invoca uno shutdown programma con argomenti da riga di comando; inoltre non sono vere con systemd. Non esiste uno shutdown separato programma a tutti.

Ogni set di strumenti di gestione del sistema ha la sua versione di queste utilità. systemd, upstart, nosh, van Smoorenburg init e BSD init tutti hanno il proprio halt , shutdown , e così via. Su ciascuno i loro meccanismi sono leggermente diversi. Così sono le loro pagine di manuale.

Nel set di strumenti di sistema halt ,shutdown ,reboot , telinit e shutdown sono tutti collegamenti simbolici a /bin/systemctl . Sono tutti shim di compatibilità con le versioni precedenti, che sono semplicemente scorciatoie per invocare l'interfaccia della riga di comando principale di systemd:systemctl . Tutti mappano (e in effetti lo sono) lo stesso singolo programma. (Per convenzione, la shell le dice con quale nome è stata invocata.)

obiettivi, non runlevel

La maggior parte di questi comandi sono scorciatoie per dire a systemd, usando systemctl , per isolare un particolare obiettivo . L'isolamento è spiegato in systemctl pagina manuale (qv), ma può essere, ai fini di questa risposta, pensato come avviare un obiettivo e fermarne altri. I target standard usati in systemd sono elencati in systemd.special (8) pagina di manuale.

I diagrammi sul bootup (7) la pagina di manuale nel set di strumenti di sistema, in particolare l'ultimo, mostra che ci sono tre obiettivi "finali" che sono rilevanti qui:

• halt.target — Una volta che il sistema ha raggiunto lo stato di isolamento completo di questo target, avrà chiamato il reboot(RB_HALT_SYSTEM) chiamata di sistema. Il kernel avrà tentato di entrare in un programma di monitoraggio della ROM, o semplicemente ha arrestato la CPU (usando qualsiasi meccanismo appropriato per farlo).
• reboot.target — Una volta che il sistema ha raggiunto lo stato di isolamento completo di questo target, avrà chiamato il reboot(RB_AUTOBOOT) chiamata di sistema (o l'equivalente con la riga di comando magica). Il kernel avrà tentato di attivare un riavvio.
• poweroff.target — Una volta che il sistema ha raggiunto lo stato di isolamento completo di questo target, avrà chiamato il reboot(RB_POWER_OFF) chiamata di sistema. Il kernel avrà tentato di rimuovere l'alimentazione dal sistema, se possibile.

Questi sono le cose a cui dovresti pensare come afferma il sistema finale, non i livelli di esecuzione. Nota dal diagramma che il sistema di destinazione systemd stesso codifica cose che, in altri sistemi, sono implicite piuttosto che esplicite:come l'idea che ciascuna di queste destinazioni finali comprenda shutdown.target target, in modo da descrivere i servizi che devono essere arrestati prima dell'arresto in quanto in conflitto con il shutdown.target obiettivo.

systemctl tenta di inviare richieste a systemd-logind quando l'utente chiamante non è il superutente. Passa anche gli arresti ritardati a systemd-shutdownd . E alcune abbreviazioni attivano wall notifiche. A parte quelle complessità, che renderebbero questa risposta molte volte più lunga, supponendo che tu sia attualmente il superutente e non richieda un'azione pianificata:

• systemctl isolate halt.target ha le abbreviazioni:
  • shutdown -H now
  • systemctl halt
  • Semplicemente disadorno halt
• systemctl isolate reboot.target ha le abbreviazioni:
  • shutdown -r now
  • telinit 6
  • systemctl reboot
  • Semplicemente disadorno reboot
• systemctl isolate poweroff.target ha le abbreviazioni:
  • shutdown -P now
  • telinit 0
  • shutdown now
  • systemctl poweroff
  • Semplicemente disadorno shutdown
• systemctl isolate rescue.target ha le abbreviazioni:
  • telinit 1
  • systemctl rescue
• systemctl isolate multi-user.target ha le abbreviazioni:
  • telinit 2
  • telinit 3
  • telinit 4
• systemctl isolate graphical.target ha l'abbreviazione:
  • telinit 5

Dopo aver analizzato le diverse sintassi della riga di comando, queste alla fine finiscono negli stessi percorsi di codice all'interno di systemctl programma.

Note:

• Il comportamento tradizionale di shutdown now senza opzioni è stato quello di passare alla modalità utente singolo . Questo non è il caso di systemd. rescue.target — la modalità per utente singolo è stata rinominata modalità di salvataggio in systemd — non è raggiungibile con shutdown comando.
• telinit lo fa davvero ignora completamente tutti quei runlevelN.target e default.target collegamenti simbolici nel filesystem che descrivono le pagine di manuale. Le suddette mappature sono cablate nel systemctl programma, in una tabella.
• systemd non ha la nozione di un livello di esecuzione corrente . Il funzionamento di questi comandi non è condizionato da "se sei a livello di esecuzione N “.
• Il --force opzione per halt , reboot e shutdown comandi è come dire --force --force all'systemctl halt , systemctl reboot e systemctl poweroff comandi. Questo rende systemctl prova a chiamare reboot() direttamente. Normalmente cerca solo di isolare gli obiettivi.
• telinit non è lo stesso di init . Sono programmi diversi nel mondo systemd, quest'ultimo è un altro nome per systemd programma, non per il systemctl programma. Il systemd il programma non è necessariamente compilato con alcuna compatibilità con van Smoorenburg e su alcuni sistemi operativi systemd si lamenta di essere invocato in modo errato se si tenta init N .

Ulteriori letture

• Ci sono buone ragioni per fermare il sistema senza tagliare la potenza?
• Perché `init 0` genera "Argomenti in eccesso" nell'installazione di Arch?
• Stephen Wadeley (2014). “8. Gestione dei servizi con systemd” Red Hat Enterprise Linux 7 System Administrators' Guide . Cappello Rosso.
• Lennart Poettering (07-10-2013). systemctl . pagine di manuale di sistema. freedesktop.org.
• Lennart Poettering (07-10-2013). systemd.special . pagine di manuale di sistema. freedesktop.org.
• Lennart Poettering (07-10-2013). bootup . pagine di manuale di sistema. freedesktop.org.
• Jonathan de Boyne Pollard (2018). init . Guida al gusto . Software.