Y ahora, la respuesta del sistema.
Está utilizando, según la etiqueta de su pregunta, Red Hat Enterprise Linux. Desde la versión 7, que ha usado systemd. Ninguna de las otras respuestas son correctas para el mundo de systemd; ni siquiera son algunos de los supuestos en su pregunta.
- Olvídate de los niveles de ejecución ; existen, pero solo como calzas de compatibilidad. La documentación de systemd establece que el concepto es "obsoleto". Si está comenzando a aprender estas cosas en un sistema operativo systemd, no comience allí.
- Olvídate de la página del manual que marcelm citó; no es del conjunto de herramientas correcto en absoluto, y es una descripción del comando de otro conjunto de herramientas, incorrecto para systemd. Es el del
halt
comando de las utilidades "System 5" de Van Smoorenburg init
.
- Ignorar las declaraciones que
/sbin/halt
es un enlace simbólico a /sbin/reboot
; Eso no es cierto con systemd. No hay ningún reboot
programa separado en absoluto.
- No haga caso de las declaraciones que
halt
o reboot
invocar un shutdown
programa con argumentos de línea de comandos; tampoco son ciertas con systemd. No hay ningún shutdown
programa separado en absoluto.
Cada conjunto de herramientas de administración del sistema tiene su versión de estas utilidades. systemd, advenedizo, nosh , van Smoorenburg init
, BSD y init
todos tienen su propia halt
, poweroff
y así sucesivamente. En cada uno sus mecanismos son ligeramente diferentes. Así son sus páginas de manual.
En el conjunto de herramientas systemd halt
, poweroff
,reboot
, telinit
, y shutdown
son todos los enlaces simbólicos a /bin/systemctl
. Son todas las cuñas compatibilidad hacia atrás, que son simplemente abreviaturas para invocar la interfaz de línea de comandos principal de systemd: systemctl
. Todos se asignan a (y de hecho son) ese mismo programa único . (Por convención, el shell le dice con qué nombre ha sido invocado).
objetivos, no niveles de ejecución
La mayoría de esos comandos son shorthands para decirle a systemd, usar systemctl
, para aislar un objetivo particular . El aislamiento se explica en la systemctl
página del manual (qv), pero se puede considerar, a los efectos de esta respuesta, como iniciar un objetivo y detener cualquier otro. Los objetivos estándar utilizados en systemd se enumeran en la systemd.special
(8) página del manual.
Los diagramas en la bootup
página del manual (7) en el conjunto de herramientas systemd, en particular el último, muestran que hay tres objetivos "finales" que son relevantes aquí:
halt.target
- Una vez que el sistema ha alcanzado el estado de aislar completamente este objetivo, habrá llamado la llamada al reboot(RB_HALT_SYSTEM)
sistema. El kernel habrá intentado ingresar a un programa de monitor ROM, o simplemente detuvo la CPU (utilizando cualquier mecanismo apropiado para hacerlo).
reboot.target
- Una vez que el sistema ha alcanzado el estado de aislar completamente este objetivo, habrá llamado la llamada al reboot(RB_AUTOBOOT)
sistema (o el equivalente con la línea de comando mágico). El núcleo habrá intentado activar un reinicio.
poweroff.target
- Una vez que el sistema ha alcanzado el estado de aislar completamente este objetivo, habrá llamado la llamada al reboot(RB_POWER_OFF)
sistema. El núcleo habrá intentado eliminar la energía del sistema, si es posible.
Estas son las cosas en las que debería estar pensando en los estados finales del sistema, no en los niveles de ejecución. Observe en el diagrama que el sistema de destino systemd mismo codifica cosas que, en otros sistemas, son implícitas en lugar de explícitas: como la noción de que cada uno de estos objetivos finales abarca el shutdown.target
objetivo, de modo que uno describe los servicios que deben detenerse antes del apagado por hacer que entren en conflicto con el shutdown.target
objetivo.
systemctl
intenta enviar solicitudes a systemd-logind
cuando el usuario que llama no es el superusuario. También pasa a los retrasos en los cierres systemd-shutdownd
. Y algunas manos cortas activan wall
notificaciones. Dejando a un lado esas complejidades, lo que haría que esta respuesta fuera varias veces más larga, suponiendo que usted es actualmente el superusuario y no solicita una acción programada:
systemctl isolate halt.target
tiene las manos cortas:
shutdown -H now
systemctl halt
- simplemente sin adornos
halt
systemctl isolate reboot.target
tiene las manos cortas:
shutdown -r now
telinit 6
systemctl reboot
- simplemente sin adornos
reboot
systemctl isolate poweroff.target
tiene las manos cortas:
shutdown -P now
telinit 0
shutdown now
systemctl poweroff
- simplemente sin adornos
poweroff
systemctl isolate rescue.target
tiene las manos cortas:
telinit 1
systemctl rescue
systemctl isolate multi-user.target
tiene las manos cortas:
telinit 2
telinit 3
telinit 4
systemctl isolate graphical.target
tiene la taquigrafía:
Después de analizar las diferentes sintaxis de línea de comandos, todas estas terminan en las mismas rutas de código dentro del systemctl
programa.
Notas:
- El comportamiento tradicional de la opción sin opciones
shutdown now
ha sido cambiar al modo de usuario único . Este no es el caso con systemd. rescue.target
- el modo de usuario único se renombra como modo de rescate en systemd - no se puede acceder con el shutdown
comando.
telinit
realmente ignora por completo todos esos y enlaces simbólicos en el sistema de archivos que describen las páginas del manual. Las asignaciones anteriores están cableadas al programa, en una tabla.runlevelN.target
default.target
systemctl
- systemd no tiene noción de un nivel de ejecución actual . El funcionamiento de estos comandos no está condicionado a ningún "si está en el nivel de ejecución N ".
- La
--force
opción de la halt
, reboot
y poweroff
comandos es lo mismo que decir --force --force
a los systemctl halt
, systemctl reboot
y systemctl poweroff
los comandos. Esto hace que systemctl
intente llamar reboot()
directamente. Normalmente solo trata de aislar objetivos.
telinit
No es lo mismo que init
. Son programas diferentes en el mundo systemd, siendo este último otro nombre para el systemd
programa, no para el systemctl
programa. El systemd
programa no está necesariamente compilado con ninguna compatibilidad de Van Smoorenburg, y en algunos sistemas operativos systemd se queja de ser invocado incorrectamente si se intenta .init N
Otras lecturas