A teraz systemowa odpowiedź.
Używasz, zgodnie ze znacznikiem na swoim pytaniu, Red Hat Enterprise Linux. Od wersji 7 używano systemd. Żadna z pozostałych odpowiedzi nie jest poprawna dla świata systemd; ani nawet niektóre z założeń w twoim pytaniu.
- Zapomnij o poziomach pracy ; istnieją, ale tylko jako podkładki kompatybilności. Systemowa dokumentacja stwierdza, że koncepcja jest „przestarzała”. Jeśli zaczynasz uczyć się tego na systemowym systemie operacyjnym, nie zaczynaj.
- Zapomnij o stronie podręcznika, którą zacytował marcelm; wcale nie pochodzi z odpowiedniego zestawu narzędzi i jest opisem polecenia innego zestawu narzędzi, niepoprawnym dla polecenia systemd. Jest to
haltpolecenie dla narzędzi van Smoorenburg „System 5” init.
- Zignoruj stwierdzenia, które
/sbin/haltsą dowiązaniem symbolicznym /sbin/reboot; to nie jest prawda z systemd. W ogóle nie ma osobnego rebootprogramu.
- Zignoruj instrukcje, które
haltlub rebootwywołują shutdownprogram z argumentami wiersza poleceń; nie są one również zgodne z systemd. W ogóle nie ma osobnego shutdownprogramu.
Każdy zestaw narzędzi do zarządzania systemem ma swoją wersję tych narzędzi. Systemd, dorobkiewicz, nosh , van Smoorenburg initi BSD initmają swoje własne halt, poweroffi tak dalej. Na każdym mechanika jest nieco inna. Podobnie jak ich strony podręcznika.
W Systemd zestawu narzędzi halt, poweroff,reboot , telinit, i shutdownsą wszystkie linki symboliczne /bin/systemctl. Są wszystkie podkładki wstecznej kompatybilności, które są po prostu dla shorthands powołując interfejs wiersza poleceń podstawową Systemd za: systemctl. Wszystkie mapują na (i tak naprawdę są) ten sam pojedynczy program. (Zgodnie z konwencją powłoka informuje ją o nazwie, do której została wywołana).
cele, a nie poziomy pracy
Większość tych poleceń jest skrótem do informowania systemd, za pomocą systemctl, do izolowania określonego celu . Izolacja jest wyjaśniona na systemctlstronie podręcznika (qv), ale dla celów tej odpowiedzi może być uważana za rozpoczęcie celu i powstrzymanie innych. Standardowe cele używane w systemd są wymienione na stronie systemd.special(8) podręcznika.
Schematy na bootup(7) stronie podręcznika w zestawach narzędzi systemowych, w szczególności ten ostatni, pokazują, że istnieją trzy „ostateczne” cele, które są tutaj istotne:
halt.target- Gdy system osiągnie stan pełnej izolacji tego celu, wywoła reboot(RB_HALT_SYSTEM)wywołanie systemowe. Jądro będzie próbowało wejść do programu monitorującego ROM lub po prostu zatrzymało procesor (używając odpowiedniego do tego mechanizmu).reboot.target- Gdy system osiągnie stan pełnej izolacji tego celu, wywoła reboot(RB_AUTOBOOT)wywołanie systemowe (lub odpowiednik magicznej linii poleceń). Jądro podejmie próbę ponownego uruchomienia komputera.poweroff.target- Gdy system osiągnie stan pełnej izolacji tego celu, wywoła reboot(RB_POWER_OFF)wywołanie systemowe. Jądro będzie próbowało usunąć zasilanie z systemu, jeśli to możliwe.
Są to rzeczy, o których powinieneś myśleć, jak stwierdza końcowy system, a nie poziomy uruchamiania. Zauważ z diagramu, że systemowy system docelowy sam koduje rzeczy, które w innych systemach są raczej niejawne, a nie jawne: na przykład pojęcie, że każdy z tych ostatecznych celów obejmuje shutdown.targetcel, tak że opisuje się usługi, które muszą zostać zatrzymane przed zamknięciem przez po nich sprzeczne z tym shutdown.targetcelem.
systemctlpróbuje wysłać żądania, systemd-logindgdy użytkownik wywołujący nie jest superużytkownikiem. Przechodzi również opóźnione przestoje do systemd-shutdownd. Niektóre skróty uruchamiają wallpowiadomienia. Pomijając te złożoności, które spowodowałyby, że ta odpowiedź byłaby kilka razy dłuższa, zakładając, że jesteś obecnie superużytkownikiem i nie żądasz zaplanowanej akcji:
systemctl isolate halt.target ma skróty:
shutdown -H nowsystemctl halt- zwykły bez ozdoby
halt
systemctl isolate reboot.target ma skróty:
shutdown -r nowtelinit 6systemctl reboot- zwykły bez ozdoby
reboot
systemctl isolate poweroff.target ma skróty:
shutdown -P nowtelinit 0shutdown nowsystemctl poweroff- zwykły bez ozdoby
poweroff
systemctl isolate rescue.target ma skróty:
telinit 1 systemctl rescue
systemctl isolate multi-user.target ma skróty:
telinit 2telinit 3telinit 4
systemctl isolate graphical.target ma skrót:
Po przeanalizowaniu różnych składni wiersza poleceń, wszystkie ostatecznie kończą się tymi samymi ścieżkami kodu w systemctlprogramie.
Uwagi:
- Tradycyjne zachowanie bez opcji polegało
shutdown nowna przełączeniu do trybu pojedynczego użytkownika . Nie jest tak w przypadku systemd. rescue.target- zmiana nazwy trybu pojedynczego użytkownika na tryb ratunkowy w systemie - nie jest osiągalna za pomocą shutdownpolecenia.
telinit naprawdę całkowicie ignoruje wszystkie te i dowiązania symboliczne w systemie plików, które opisują strony podręcznika. Powyższe odwzorowania są wbudowane w program, w formie tabeli.runlevelN.targetdefault.targetsystemctl- systemd nie ma pojęcia o bieżącym poziomie uruchamiania . Działanie tych poleceń nie jest uzależnione od żadnego „jeśli jesteś na poziomie uruchomienia N ”.
--forceOpcja do halt, rebooti poweroffpolecenia jest taki sam, jak mówią --force --forcedo systemctl halt, systemctl rebooti systemctl poweroffpoleceń. To sprawia, że systemctlspróbuj zadzwonić reboot()bezpośrednio. Zwykle po prostu próbuje izolować cele.telinitto nie to samo co init. Są to różne programy w świecie systemowym, przy czym ta ostatnia jest inną nazwą dla systemdprogramu, a nie dla systemctlprogramu. systemdProgram nie jest koniecznie skompilowany z dowolnego kompatybilności van Smoorenburg w ogóle, a na niektórych systemach operacyjnych Systemd narzeka powołano nieprawidłowo Jeśli jeden prób .init N
Dalsza lektura