Risposte:
at 18:00 shutdown nowcrea un lavoro "at", che viene eseguito all'ora specificata dal atdemone o forse dal crondemone, a seconda del sistema.
shutdown 18:00avvia un processo nella shell che attende fino al tempo specificato e quindi esegue l'arresto. Questo comando può essere terminato se, ad esempio, la sessione della shell è terminata.
Il risultato netto nella maggior parte dei casi sarà lo stesso: il sistema si arresta alle 18:00.
Una differenza è che se si utilizza at, il lavoro verrà archiviato e se il sistema viene arrestato in qualche modo prima delle 18:00, al riavvio il lavoro sarà ancora in attesa di essere eseguito; se il tempo è già passato, l'arresto verrà eseguito immediatamente, il che potrebbe essere abbastanza inaspettato.
Un'altra differenza è che shutdown 18:00creerà un /run/nologinfile 5 minuti prima dell'orario previsto per impedire alle persone di accedere dopo quel momento. Inoltre, i messaggi di trasmissione verranno inviati per avvisare gli utenti registrati che il sistema sta per essere arrestato.
È necessario tenere conto di queste differenze per decidere quale utilizzare.
nohupo disowno qualsiasi altra cosa, se il logout normalmente uccide in esecuzione processi in background. Sistemi diversi possono avere impostazioni predefinite diverse. (Suppongo che ci sia davvero un sudo shutdownprocesso ancora in esecuzione, piuttosto che segnali solo initdi avviare un timer di spegnimento. Quest'ultimo potrebbe effettivamente essere quello che succede, ma non ho verificato di recente. Oh, ma ha @JdeBP; vedi quella risposta )
atmodo che funzioni tramite cronanziché atd?
Se hai CentOS 7, hai un sistema operativo systemd e la risposta è diversa.
at 18:00 shutdown nowpianifica ancora tramite il atsottosistema, ma quel shutdowncomando, così come quello con cui invochi direttamente shutdown 18:00, è diverso. In realtà è il systemctlprogramma di systemd . systemctlfa le cose diversamente.
Prima di tutto, systemctlinvia la richiesta di arresto pianificato per essere elaborata da un demone, praticamente come nel atcaso. Questo è un sistema e un demone, nello specifico logind(il systemd-shutdownddemone è stato rimosso da systemd nel maggio 2015, che da allora ha cambiato le versioni secondarie di CentOS 7), non il atsottosistema. systemctlparla di un protocollo interno a un broker di bus desktop (a livello di sistema) che a sua volta comunica logind.
Quindi, come nel atcaso, non c'è alcun shutdownprocesso seduto lì a fare il conto alla rovescia e generare i wallmessaggi. Quindi è possibile disconnettersi e ciò non influirà sulla pianificazione e la cancellazione non è così semplice come semplicemente interrompere / terminare il processo in primo piano della sessione di accesso. Proprio come con at.
Ci sono ancora messaggi, a differenza del atcaso, ma sono emessi da logind. Inoltre, diversamente dal atcaso, il processo pianificato non persiste per tutti i riavvii del sistema, quindi un arresto effettivo ne annulla uno pianificato. V'è un file nel file system, ma è sotto /run/systemd/shutdown, che è di stoccaggio non-persistente.
Ulteriori differenze sono che può esserci un solo arresto programmato alla volta, mentre è possibile inoltrare più atlavori e il Policy Kit applicherà le regole da shutdowneseguire in un contesto di sessione non di accesso come atlavoro diverso dalle regole applicate per l' shutdownesecuzione contesto della sessione di accesso. Quest'ultimo potrebbe essere più permissivo, consentendo (diciamo) a un utente non privilegiato che ha effettuato l'accesso alla sessione di accesso attiva di arrestare il sistema.
shutdown 18:00avvia un processo nella shell che attende". Cosa succede se esci prima di allora?