¿Systemd todavía tiene el concepto de niveles de ejecución? Por ejemplo, ¿no tiene sentido usarlo telinit <number>?

SystemD Run-Level Low-Down

Dentro de SystemD (aemon), los niveles de ejecución se exponen como "Objetivos". El concepto sigue ahí, pero el flujo de trabajo para producir el resultado deseado para sus necesidades es diferente.

El adjunto debe aclarar este problema.

¿Cómo cambio el nivel de ejecución actual?

$ systemctl isolate runlevelX.target

¿Cómo cambio el nivel de ejecución predeterminado para el siguiente arranque?

# Create a symlink
$ ln -sf /usr/lib/systemd/system/multi-user.target /etc/systemd/system/default.target

• ln -sf TARGET DESTINATION
• -s crea un enlace simbólico
• -f elimina el archivo de destino existente

O (como sugirió @centimane) simplemente use el systemdcomando "bendito" :

systemctl set-default [target name].target

¿Cómo identifico el nivel de ejecución actual?

$ systemctl list-units --type=target

No. Como la gente del sistema mismo escribió dos veces, una en su telinitmanual y otra en su runlevelmanual, los niveles de ejecución son "obsoletos". Puedes olvidarte de los niveles de ejecución.

Estas cosas no existen en absoluto en systemd, con algunas cuñas de compatibilidad.

• Hay algunos enlaces simbólicos para los nombres de los objetivos, pero estos objetivos nunca los usa realmente systemd.
  • Más bien, el proceso bootstrap emplea a default.target(y de ahí uno o ambos de a graphical.targety a multi-user.target), a rescue.targeto an emergency.target. Y el proceso de apagado involucra a shutdown.target, a reboot.target, a halt.targeto a poweroff.target. No hay objetivos de nivel de ejecución involucrados ni en bootstrap ni en apagado.
  • El telinitcomando, que uno podría pensar que usa los enlaces simbólicos de compatibilidad para mapear sus argumentos de línea de comandos, tampoco lo hace. Hay una mesa de cableado en el código fuente del telinitprograma, y los números 2, 3, 4, y 5como argumentos para el comando están cableados para asignar a multi-user.targety graphical.target.
  • systemd-update-utmp También tiene una mesa interna cableada.
• No hay una "tabla de inicio" de cosas de nivel de ejecución. systemd solo es compatible con van Smoorenburg rc, no con van Smoorenburg init.
• No hay ningún valor de "nivel de ejecución actual" mantenido por el propio systemd. Más bien, la casi totalmente indocumentado systemd-update-utmpcomando opera internamente en términos de la activación de los estados rescue.target, multi-user.targety graphical.target.
• systemd-sysv-generator, el generador de unidades de servicio de compatibilidad con versiones anteriores de systemd, combina los /etc/rc[234].ddirectorios en una sola Wanted-Byrelación con multi-user.targetlas unidades de servicio generadas. No existe una referencia real para ejecutar niveles en las unidades de servicio generadas. (Solía ​​haber, hace años, pero la gente del sistema descubrió que esto salió mal, porque no estaban siendo referenciados en ningún otro lugar).

Si uno es un usuario de un sistema que construye systemd como lo hizo Arch Linux para el interrogador en " ¿Por qué` init 0` da como resultado "Exceso de argumentos" en la instalación de Arch? ", Uno ni siquiera obtiene las cuñas de compatibilidad, y ordena como init 0resultado en el comportamiento systemd "nativo", que consiste en quejarse de que el comando ha sido invocado incorrectamente.

Otras lecturas

• Lennart Poettering y cols runlevel. páginas de manual de systemd. Freedesktop.org.
• Lennart Poettering y cols telinit. páginas de manual de systemd. Freedesktop.org.
• Lennart Poettering y cols bootup. páginas de manual de systemd. Freedesktop.org.
• Lennart Poettering (2015-02-08). en todas partes: elimine la configurabilidad del nivel de ejecución sysv al mapeo de destino . systemd. github
• /unix//a/196014/5132
• /unix//a/196197/5132
• /unix//a/233581/5132
• /unix//a/211927/5132
• /unix//a/392612/5132
• Jonathan de Boyne Pollard (2015). /etc/inittabEs cosa del pasado. . Respuestas frecuentes.

Muchas gracias. Entonces, si entendí correctamente:

Por ejemplo:

ls -ll /usr/lib/systemd/system/runlevel*.target

Salida:

/usr/lib/systemd/system/runlevel0.target -> poweroff.target
/usr/lib/systemd/system/runlevel1.target -> rescue.target
/usr/lib/systemd/system/runlevel2.target -> multi-user.target
/usr/lib/systemd/system/runlevel3.target -> multi-user.target
/usr/lib/systemd/system/runlevel4.target -> multi-user.target
/usr/lib/systemd/system/runlevel5.target -> graphical.target
/usr/lib/systemd/system/runlevel6.target -> reboot.target

Como puede ver, el concepto de niveles de ejecución existe, pero es bastante obsoleto debido al hecho de que los archivos runlevel.target no son en realidad archivos "reales" sino enlaces suaves al esquema de archivos nuevo, moderno y mejor nombrado que A systemd le gusta llamarlos "objetivos".

Entonces, si desea hacer algo así telinit 5, sería así: systemctl isolate runlevel5.target que es idéntico a: systemctl isolate graphical.target(recomendado en mi opinión).

En caso de que esté interesado en conocer todos los objetivos posibles:

ls /usr/lib/systemd/system/*.target

systemd introdujo objetivos como contrapartida de los niveles de ejecución en el sistema de inicio sysV. Los desarrolladores de sytemd lo hicieron casi compatible con la mayoría de los scripts sysV. Lo mismo sucede para telinit <runlevel>. Esto se traduce a systemd equivalente.

Por ejemplo telinit 0, apaga la máquina. systemd tiene poweroff.target para hacer lo mismo que runlevel 0 . Entonces telinit 0es traducido por systemd para activar poweroff.target .

Pero existen algunos problemas de compatibilidad con los sistemas de inicio sytemd y sysV-> https://www.freedesktop.org/wiki/Software/systemd/Incompatibilities .