Odpowiedzi:
at 18:00 shutdown now
tworzy zadanie „at”, które jest wykonywane w określonym czasie przez at
demona lub może cron
demona, w zależności od systemu.
shutdown 18:00
uruchamia proces w powłoce, który czeka do określonego czasu, a następnie wykonuje zamknięcie. To polecenie może zostać zakończone, jeśli np. Sesja powłoki zostanie zakończona.
Wynik netto w większości przypadków będzie taki sam: system zostanie zamknięty o godzinie 18:00.
Jedną różnicą jest to, że jeśli użyjesz at
, zadanie zostanie zapisane, a system zostanie zamknięty w inny sposób przed godziną 18:00, po ponownym uruchomieniu zadanie będzie nadal czekało na uruchomienie; jeśli czas już minął, zamknięcie zostanie wykonane natychmiast, co może być dość nieoczekiwane.
Kolejną różnicą jest to, że shutdown 18:00
utworzy /run/nologin
plik na 5 minut przed zaplanowanym czasem, aby uniemożliwić zalogowanie się po tym momencie. Zostaną również wysłane wiadomości rozgłoszeniowe, aby ostrzec zalogowanych użytkowników, że system ma się zamknąć.
Musisz wziąć pod uwagę te różnice, aby zdecydować, którego użyć.
nohup
czy disown
cokolwiek innego, jeśli wylogowanie normalnie zabije uruchomione procesy w tle. Różne systemy mogą mieć różne ustawienia domyślne. (Zakładam, że naprawdę sudo shutdown
nadal działa proces, a raczej sygnalizujący init
uruchomienie wyłącznika czasowego. Ten ostatni może być tym, co się dzieje, ale ostatnio tego nie sprawdzałem. Och, ale @JdeBP ma; zobacz tę odpowiedź )
at
aby działało cron
zamiast atd
?
Jeśli masz CentOS 7, masz systemowy system operacyjny i odpowiedź jest inna.
at 18:00 shutdown now
nadal planuje za pośrednictwem at
podsystemu, ale to shutdown
polecenie, podobnie jak to, które wywołujesz bezpośrednio shutdown 18:00
, jest inne. To właściwie systemctl
program systemowy . systemctl
robi rzeczy inaczej.
Po pierwsze, systemctl
wysyła zaplanowane żądanie zamknięcia do przetworzenia przez demona, podobnie jak w at
przypadku. Jest to jednak systemowy demon, a konkretnie logind
( systemd-shutdownd
demon został usunięty z systemd w maju 2015 r., Którego zmiana odtąd przeniknęła do późniejszych mniejszych wersji CentOS 7), a nie at
podsystem. systemctl
odczytuje wewnętrzny protokół z (ogólnosystemowym) brokerem Desktop Bus, który z kolei się komunikuje logind
.
Podobnie jak w at
przypadku, nie ma shutdown
procesu odliczającego i odradzającego wall
wiadomości. Można się więc wylogować, a to nie wpłynie na harmonogram, a anulowanie nie jest tak proste, jak zwykłe przerwanie / zabicie pierwszego planu sesji logowania. Tak jak z at
.
Nadal są wiadomości, w przeciwieństwie do at
przypadku, ale są one wysyłane przez logind
. Również w odróżnieniu od at
przypadku, zaplanowane zadanie nie utrzymuje się podczas ponownego uruchamiania systemu, więc faktyczne zamknięcie anuluje zaplanowane. W systemie plików znajduje się plik, ale pod nim /run/systemd/shutdown
znajduje się pamięć trwała.
Kolejne różnice polegają na tym, że może być tylko jedno zaplanowane zamknięcie na raz, podczas gdy można przesłać wiele at
zadań, a Zestaw zasad zastosuje reguły do shutdown
uruchamiania w kontekście sesji bez logowania jako at
zadanie, które jest inne niż reguły zastosowane do shutdown
uruchomienia w kontekst sesji logowania. Ten ostatni może być bardziej liberalny, pozwalając (powiedzmy) nieuprzywilejowanemu użytkownikowi, który jest zalogowany do aktywnej sesji logowania, aby zamknąć system.
shutdown 18:00
uruchamia proces w twojej powłoce, który czeka”. Co jeśli wylogujesz się wcześniej?