Comprender systemd al inicio en Linux

En Aprender a amar systemd , el primer artículo de esta serie, analicé las funciones y la arquitectura de systemd y la controversia en torno a su papel como reemplazo del antiguo programa de inicio SystemV y los scripts de inicio. En este segundo artículo, comenzaré a explorar los archivos y las herramientas que administran la secuencia de inicio de Linux. Explicaré la secuencia de inicio de systemd, cómo cambiar el destino de inicio predeterminado (nivel de ejecución en términos de SystemV) y cómo cambiar manualmente a un destino diferente sin tener que reiniciar.

También veré dos herramientas systemd importantes. El primero es el systemctl comando, que es el medio principal para interactuar y enviar comandos a systemd. El segundo es journalctl , que proporciona acceso a los diarios systemd que contienen grandes cantidades de datos del historial del sistema, como mensajes del kernel y del servicio (tanto informativos como de error).

Asegúrese de utilizar un sistema que no sea de producción para las pruebas y la experimentación en este y futuros artículos. Su sistema de prueba debe tener instalado un escritorio GUI (como Xfce, LXDE, Gnome, KDE u otro).

Escribí en mi artículo anterior que planeaba crear una unidad systemd y agregarla a la secuencia de inicio en este artículo. Debido a que este artículo se hizo más largo de lo que esperaba, lo guardaré para el próximo artículo de esta serie.

Explorando el inicio de Linux con systemd

Más sobre administradores de sistemas

• Habilitar el blog de administrador del sistema
• La empresa automatizada:una guía para administrar TI con automatización
• Libro electrónico:Automatización de Ansible para administradores de sistemas
• Historias del campo:una guía del administrador de sistemas para la automatización de TI
• eBook:Una guía de Kubernetes para SRE y administradores de sistemas
• Últimos artículos de administrador de sistemas

Antes de que pueda observar la secuencia de inicio, debe hacer un par de cosas para que las secuencias de inicio y de inicio estén abiertas y visibles. Normalmente, la mayoría de las distribuciones utilizan una animación de inicio o una pantalla de inicio para ocultar los mensajes detallados que, de otro modo, se mostrarían durante el inicio y el apagado de un host de Linux. Esto se llama la pantalla de inicio de Plymouth en las distribuciones basadas en Red Hat. Esos mensajes ocultos pueden proporcionar una gran cantidad de información sobre el inicio y el apagado a un administrador de sistemas que busca información para solucionar un error o simplemente aprender sobre la secuencia de inicio. Puede cambiar esto usando la configuración de GRUB (Grand Unified Boot Loader).

El archivo de configuración principal de GRUB es /boot/grub2/grub.cfg , pero debido a que este archivo se puede sobrescribir cuando se actualiza la versión del kernel, no desea cambiarlo. En su lugar, modifique el /etc/default/grub archivo, que se utiliza para modificar la configuración predeterminada de grub.cfg .

Comience mirando la versión actual sin modificar de /etc/default/grub archivo:

[root@testvm1 ~]# cd /etc/default ; cat grub

GRUB_TIMEOUT=5

GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"

GRUB_DEFAULT=saved

GRUB_DISABLE_SUBMENU=true

GRUB_TERMINAL_OUTPUT="console"

GRUB_CMDLINE_LINUX="resume=/dev/mapper/fedora_testvm1-swap rd.lvm.

lv=fedora_testvm1/root rd.lvm.lv=fedora_testvm1/swap rd.lvm.lv=fedora_

testvm1/usr rhgb quiet"

GRUB_DISABLE_RECOVERY="true"

[root@testvm1 default]#

El capítulo 6 de la documentación de GRUB contiene una lista de todas las entradas posibles en /etc/default/grub archivo, pero me concentro en lo siguiente:

• Cambio GRUB_TIMEOUT , la cantidad de segundos para la cuenta regresiva del menú de GRUB, de cinco a 10 para dar un poco más de tiempo para responder al menú de GRUB antes de que la cuenta regresiva llegue a cero.
• Elimino los dos últimos parámetros en GRUB_CMDLINE_LINUX , que enumera los parámetros de la línea de comandos que se pasan al kernel en el momento del arranque. Uno de estos parámetros, rhgb significa Red Hat Graphical Boot, y muestra la pequeña animación del ícono de Fedora durante la inicialización del kernel en lugar de mostrar mensajes de tiempo de arranque. El otro, el tranquilo parámetro, evita que se muestren los mensajes de inicio que documentan el progreso del inicio y cualquier error que ocurra. Elimino ambos rhgb y tranquilo porque los administradores de sistemas necesitan ver estos mensajes. Si algo sale mal durante el arranque, los mensajes que se muestran en la pantalla pueden señalar la causa del problema.

Después de realizar estos cambios, su archivo GRUB se verá así:

[root@testvm1 default]# cat grub

GRUB_TIMEOUT=10

GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"

GRUB_DEFAULT=saved

GRUB_DISABLE_SUBMENU=true

GRUB_TERMINAL_OUTPUT="console"

GRUB_CMDLINE_LINUX="resume=/dev/mapper/fedora_testvm1-swap rd.lvm.

lv=fedora_testvm1/root rd.lvm.lv=fedora_testvm1/swap rd.lvm.lv=fedora_

testvm1/usr"

GRUB_DISABLE_RECOVERY="false"

[root@testvm1 default]#

El grub2-mkconfig programa genera el grub.cfg archivo de configuración utilizando el contenido de /etc/default/grub para modificar algunas de las configuraciones predeterminadas de GRUB. El grub2-mkconfig el programa envía su salida a STDOUT . Tiene una -o opción que le permite especificar un archivo para enviar el flujo de datos, pero es tan fácil de usar como redirección. Ejecute el siguiente comando para actualizar /boot/grub2/grub.cfg archivo de configuración:

[root@testvm1 grub2]# grub2-mkconfig > /boot/grub2/grub.cfg

Generating grub configuration file ...

Found linux image: /boot/vmlinuz-4.18.9-200.fc28.x86_64

Found initrd image: /boot/initramfs-4.18.9-200.fc28.x86_64.img

Found linux image: /boot/vmlinuz-4.17.14-202.fc28.x86_64

Found initrd image: /boot/initramfs-4.17.14-202.fc28.x86_64.img

Found linux image: /boot/vmlinuz-4.16.3-301.fc28.x86_64

Found initrd image: /boot/initramfs-4.16.3-301.fc28.x86_64.img

Found linux image: /boot/vmlinuz-0-rescue-7f12524278bd40e9b10a085bc82dc504

Found initrd image: /boot/initramfs-0-rescue-7f12524278bd40e9b10a085bc82dc504.img

done

[root@testvm1 grub2]#

Reinicie su sistema de prueba para ver los mensajes de inicio que, de lo contrario, estarían ocultos detrás de la animación de inicio de Plymouth. Pero, ¿qué sucede si necesita ver los mensajes de inicio y no ha desactivado la animación de arranque de Plymouth? ¿O lo ha hecho, pero los mensajes pasan demasiado rápido para leerlos? (Lo que hacen.)

Hay un par de opciones, y ambas involucran archivos de registro y diarios systemd, que son tus amigos. Puedes usar el menos comando para ver el contenido de /var/log/messages expediente. Este archivo contiene mensajes de arranque e inicio, así como mensajes generados por el sistema operativo durante el funcionamiento normal. También puede usar el journalctl comando sin ninguna opción para ver el diario systemd, que contiene esencialmente la misma información:

[root@testvm1 grub2]# journalctl

-- Logs begin at Sat 2020-01-11 21:48:08 EST, end at Fri 2020-04-03 08:54:30 EDT. --

Jan 11 21:48:08 f31vm.both.org kernel: Linux version 5.3.7-301.fc31.x86_64 ([email protected]) (gcc version 9.2.1 20190827 (Red Hat 9.2.1-1) (GCC)) #1 SMP Mon Oct >

Jan 11 21:48:08 f31vm.both.org kernel: Command line: BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.3.7-301.fc31.x86_64 root=/dev/mapper/VG01-root ro resume=/dev/mapper/VG01-swap rd.lvm.lv=VG01/root rd>

Jan 11 21:48:08 f31vm.both.org kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'

Jan 11 21:48:08 f31vm.both.org kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'

Jan 11 21:48:08 f31vm.both.org kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'

Jan 11 21:48:08 f31vm.both.org kernel: x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256

Jan 11 21:48:08 f31vm.both.org kernel: x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format.

Jan 11 21:48:08 f31vm.both.org kernel: BIOS-provided physical RAM map:

Jan 11 21:48:08 f31vm.both.org kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable

Jan 11 21:48:08 f31vm.both.org kernel: BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved

Jan 11 21:48:08 f31vm.both.org kernel: BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved

Jan 11 21:48:08 f31vm.both.org kernel: BIOS-e820: [mem 0x0000000000100000-0x00000000dffeffff] usable

Jan 11 21:48:08 f31vm.both.org kernel: BIOS-e820: [mem 0x00000000dfff0000-0x00000000dfffffff] ACPI data

Jan 11 21:48:08 f31vm.both.org kernel: BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved

Jan 11 21:48:08 f31vm.both.org kernel: BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved

Jan 11 21:48:08 f31vm.both.org kernel: BIOS-e820: [mem 0x00000000fffc0000-0x00000000ffffffff] reserved

Jan 11 21:48:08 f31vm.both.org kernel: BIOS-e820: [mem 0x0000000100000000-0x000000041fffffff] usable

Jan 11 21:48:08 f31vm.both.org kernel: NX (Execute Disable) protection: active

Jan 11 21:48:08 f31vm.both.org kernel: SMBIOS 2.5 present.

Jan 11 21:48:08 f31vm.both.org kernel: DMI: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006

Jan 11 21:48:08 f31vm.both.org kernel: Hypervisor detected: KVM

Jan 11 21:48:08 f31vm.both.org kernel: kvm-clock: Using msrs 4b564d01 and 4b564d00

Jan 11 21:48:08 f31vm.both.org kernel: kvm-clock: cpu 0, msr 30ae01001, primary cpu clock

Jan 11 21:48:08 f31vm.both.org kernel: kvm-clock: using sched offset of 8250734066 cycles

Jan 11 21:48:08 f31vm.both.org kernel: clocksource: kvm-clock: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns

Jan 11 21:48:08 f31vm.both.org kernel: tsc: Detected 2807.992 MHz processor

Jan 11 21:48:08 f31vm.both.org kernel: e820: update [mem 0x00000000-0x00000fff] usable ==> reserved

Jan 11 21:48:08 f31vm.both.org kernel: e820: remove [mem 0x000a0000-0x000fffff] usable

<snip>

Trunqué este flujo de datos porque puede tener cientos de miles o incluso millones de líneas. (La lista de diarios en mi estación de trabajo principal tiene 1.188.482 líneas). Asegúrese de probar esto en su sistema de prueba. Si se ha estado ejecutando durante algún tiempo, incluso si se ha reiniciado muchas veces, se mostrarán grandes cantidades de datos. Explore los datos de este diario porque contiene mucha información que puede ser muy útil al realizar la determinación de problemas. Saber cómo se ven estos datos para un inicio y un inicio normales puede ayudarlo a localizar los problemas cuando ocurren.

Discutiré las revistas systemd, la journalctl comando y cómo clasificar todos esos datos para encontrar lo que desea con más detalle en un artículo futuro de esta serie.

Después de que GRUB cargue el kernel en la memoria, primero debe extraerse de la versión comprimida del archivo antes de que pueda realizar cualquier trabajo útil. Después de que el kernel se haya extraído y comenzado a ejecutarse, carga systemd y le entrega el control.

Este es el final del proceso de arranque. En este punto, el kernel de Linux y systemd se están ejecutando pero no pueden realizar ninguna tarea productiva para el usuario final porque no se está ejecutando nada más, no hay un shell para proporcionar una línea de comando, no hay procesos en segundo plano para administrar la red u otros enlaces de comunicación, y nada que permita a la computadora realizar alguna función productiva.

Systemd ahora puede cargar las unidades funcionales requeridas para llevar el sistema a un estado de ejecución objetivo seleccionado.

Objetivos

Un destino systemd representa el estado de ejecución actual o deseado de un sistema Linux. Al igual que los scripts de inicio de SystemV, los objetivos definen los servicios que deben estar presentes para que el sistema se ejecute y esté activo en ese estado. La Figura 1 muestra los posibles objetivos de estado de ejecución de un sistema Linux que usa systemd. Como se vio en el primer artículo de esta serie y en la página del manual de systemd bootup (man bootup), hay otros objetivos intermedios que se requieren para habilitar varios servicios necesarios. Estos pueden incluir swap.target , temporizadores.objetivo , local-fs.objetivo , y más. Algunos objetivos (como basic.target ) se utilizan como puntos de control para garantizar que todos los servicios necesarios estén en funcionamiento antes de pasar al siguiente nivel superior.

A menos que se cambie lo contrario en el momento del arranque en el menú de GRUB, systemd siempre inicia el default.target . El objetivo.predeterminado El archivo es un enlace simbólico al verdadero archivo de destino. Para una estación de trabajo de escritorio, normalmente será el graphical.target , que es equivalente al nivel de ejecución 5 en SystemV. Para un servidor, es más probable que el valor predeterminado sea multi-user.target , que es como el nivel de ejecución 3 en SystemV. El objetivo.de.emergencia El archivo es similar al modo de usuario único. Los objetivos y los servicios son unidades systemd.

La siguiente tabla, que incluí en el artículo anterior de esta serie, compara los objetivos de systemd con los antiguos niveles de ejecución de inicio de SystemV. Los alias de destino de systemd son proporcionados por systemd para compatibilidad con versiones anteriores. Los alias de destino permiten que los scripts y los administradores de sistemas usen comandos de SystemV como init 3 para cambiar los niveles de ejecución. Por supuesto, los comandos de SystemV se reenvían a systemd para su interpretación y ejecución.

Cada objetivo tiene un conjunto de dependencias descritas en su archivo de configuración. systemd inicia las dependencias necesarias, que son los servicios necesarios para ejecutar el host Linux en un nivel específico de funcionalidad. Cuando todas las dependencias enumeradas en los archivos de configuración de destino están cargadas y en ejecución, el sistema se ejecuta en ese nivel de destino. Si lo desea, puede revisar la secuencia de inicio de systemd y los objetivos de tiempo de ejecución en el primer artículo de esta serie, Aprender a amar systemd .

Explorando el objetivo actual

Muchas distribuciones de Linux instalan de manera predeterminada una interfaz de escritorio GUI para que los sistemas instalados puedan usarse como estaciones de trabajo. Siempre instalo desde una unidad USB de arranque Fedora Live con un escritorio Xfce o LXDE. Incluso cuando estoy instalando un servidor u otro tipo de infraestructura de host (como los que uso para enrutadores y cortafuegos), uso una de estas instalaciones que instala un escritorio GUI.

Podría instalar un servidor sin escritorio (y eso sería típico de los centros de datos), pero eso no satisface mis necesidades. No es que necesite el escritorio de la GUI en sí, pero la instalación de LXDE incluye muchas de las otras herramientas que uso que no están en una instalación de servidor predeterminada. Esto significa menos trabajo para mí después de la instalación inicial.

Pero el hecho de que tenga un escritorio GUI no significa que tenga sentido usarlo. Tengo un KVM de 16 puertos que puedo usar para acceder a las interfaces KVM de la mayoría de mis sistemas Linux, pero la gran mayoría de mi interacción con ellos se realiza a través de una conexión SSH remota desde mi estación de trabajo principal. De esta forma es más segura y utiliza menos recursos del sistema para ejecutar multi-user.target en comparación con objetivo.gráfico.

Para comenzar, marque el objetivo predeterminado para verificar que sea el graphical.target :

[root@testvm1 ~]# systemctl get-default

graphical.target

[root@testvm1 ~]#

Ahora verifique el objetivo actualmente en ejecución. Debe ser el mismo que el objetivo predeterminado. Todavía puede usar el método anterior, que muestra los niveles de ejecución antiguos de SystemV. Tenga en cuenta que el nivel de ejecución anterior está a la izquierda; es N (que significa Ninguno), lo que indica que el nivel de ejecución no ha cambiado desde que se inició el host. El número 5 indica el objetivo actual, tal como se define en la antigua terminología de SystemV:

[root@testvm1 ~]# runlevel

N 5

[root@testvm1 ~]#

Tenga en cuenta que la página del manual de nivel de ejecución indica que los niveles de ejecución están obsoletos y proporciona una tabla de conversión.

También puede utilizar el método systemd. No hay una respuesta de una línea aquí, pero proporciona la respuesta en términos systemd:

[root@testvm1 ~]# systemctl list-units --type target

UNIT                   LOAD   ACTIVE SUB    DESCRIPTION                

basic.target           loaded active active Basic System               

cryptsetup.target      loaded active active Local Encrypted Volumes    

getty.target           loaded active active Login Prompts              

graphical.target       loaded active active Graphical Interface        

local-fs-pre.target    loaded active active Local File Systems (Pre)   

local-fs.target        loaded active active Local File Systems         

multi-user.target      loaded active active Multi-User System          

network-online.target  loaded active active Network is Online          

network.target         loaded active active Network                    

nfs-client.target      loaded active active NFS client services        

nss-user-lookup.target loaded active active User and Group Name Lookups

paths.target           loaded active active Paths                      

remote-fs-pre.target   loaded active active Remote File Systems (Pre)  

remote-fs.target       loaded active active Remote File Systems        

rpc_pipefs.target      loaded active active rpc_pipefs.target          

slices.target          loaded active active Slices                     

sockets.target         loaded active active Sockets                    

sshd-keygen.target     loaded active active sshd-keygen.target         

swap.target            loaded active active Swap                       

sysinit.target         loaded active active System Initialization      

timers.target          loaded active active Timers                     



LOAD   = Reflects whether the unit definition was properly loaded.

ACTIVE = The high-level unit activation state, i.e. generalization of SUB.

SUB    = The low-level unit activation state, values depend on unit type.



21 loaded units listed. Pass --all to see loaded but inactive units, too.

To show all installed unit files use 'systemctl list-unit-files'.

Esto muestra todos los objetivos actualmente cargados y activos. También puede ver el graphical.target y el multiusuario.objetivo . El objetivo.multiusuario se requiere antes del graphical.target se puede cargar En este ejemplo, el graphical.target está activo.

Cambiar a un objetivo diferente

Hacer el cambio a multi-user.target es fácil:

[root@testvm1 ~]# systemctl isolate multi-user.target

La pantalla ahora debería cambiar del escritorio de la GUI o la pantalla de inicio de sesión a una consola virtual. Inicie sesión y enumere las unidades systemd actualmente activas para verificar que graphical.target ya no se está ejecutando:

[root@testvm1 ~]# systemctl list-units --type target

Asegúrese de usar el nivel de ejecución Comando para verificar que muestra los "niveles de ejecución" anteriores y actuales:

[root@testvm1 ~]# runlevel

5 3

Cambiando el objetivo predeterminado

Ahora, cambie el objetivo predeterminado a multi-user.target para que siempre se inicie en el multi-user.target para una interfaz de línea de comandos de consola en lugar de una interfaz de escritorio GUI. Como usuario raíz en su host de prueba, cambie al directorio donde se mantiene la configuración de systemd y haga una lista rápida:

[root@testvm1 ~]# cd /etc/systemd/system/ ; ll

drwxr-xr-x. 2 root root 4096 Apr 25  2018  basic.target.wants

<snip>

lrwxrwxrwx. 1 root root   36 Aug 13 16:23  default.target -> /lib/systemd/system/graphical.target

lrwxrwxrwx. 1 root root   39 Apr 25  2018  display-manager.service -> /usr/lib/systemd/system/lightdm.service

drwxr-xr-x. 2 root root 4096 Apr 25  2018  getty.target.wants

drwxr-xr-x. 2 root root 4096 Aug 18 10:16  graphical.target.wants

drwxr-xr-x. 2 root root 4096 Apr 25  2018  local-fs.target.wants

drwxr-xr-x. 2 root root 4096 Oct 30 16:54  multi-user.target.wants

<snip>

[root@testvm1 system]#

Acorté esta lista para resaltar algunas cosas importantes que ayudarán a explicar cómo systemd administra el proceso de arranque. Debería poder ver la lista completa de directorios y enlaces en su máquina virtual.

El objetivo.predeterminado la entrada es un enlace simbólico (enlace simbólico, enlace suave) al directorio /lib/systemd/system/graphical.target . Enumere ese directorio para ver qué más hay:

[root@testvm1 system]# ll /lib/systemd/system/ | less

Debería ver archivos, directorios y más enlaces en esta lista, pero busque específicamente multi-user.target y objetivo.gráfico . Ahora muestra el contenido de default.target , que es un enlace a /lib/systemd/system/graphical.target :

[root@testvm1 system]# cat default.target 

#  SPDX-License-Identifier: LGPL-2.1+

#

#  This file is part of systemd.

#

#  systemd is free software; you can redistribute it and/or modify it

#  under the terms of the GNU Lesser General Public License as published by

#  the Free Software Foundation; either version 2.1 of the License, or

#  (at your option) any later version.



[Unit]

Description=Graphical Interface

Documentation=man:systemd.special(7)

Requires=multi-user.target

Wants=display-manager.service

Conflicts=rescue.service rescue.target

After=multi-user.target rescue.service rescue.target display-manager.service

AllowIsolate=yes

[root@testvm1 system]#

Este enlace a graphical.target El archivo describe todos los requisitos previos y requisitos que requiere la interfaz gráfica de usuario. Exploraré al menos algunas de estas opciones en el próximo artículo de esta serie.

Para permitir que el host arranque en modo multiusuario, debe eliminar el enlace existente y crear uno nuevo que apunte al destino correcto. Haga que el PWD /etc/systemd/system , si no lo está ya:

[root@testvm1 system]# rm -f default.target 

[root@testvm1 system]# ln -s /lib/systemd/system/multi-user.target default.target

Indique el objetivo.predeterminado enlace para verificar que enlaza con el archivo correcto:

[root@testvm1 system]# ll default.target 

lrwxrwxrwx 1 root root 37 Nov 28 16:08 default.target -> /lib/systemd/system/multi-user.target

[root@testvm1 system]#

Si su enlace no se ve exactamente así, elimínelo y vuelva a intentarlo. Enumere el contenido del default.target enlace:

[root@testvm1 system]# cat default.target 

#  SPDX-License-Identifier: LGPL-2.1+

#

#  This file is part of systemd.

#

#  systemd is free software; you can redistribute it and/or modify it

#  under the terms of the GNU Lesser General Public License as published by

#  the Free Software Foundation; either version 2.1 of the License, or

#  (at your option) any later version.



[Unit]

Description=Multi-User System

Documentation=man:systemd.special(7)

Requires=basic.target

Conflicts=rescue.service rescue.target

After=basic.target rescue.service rescue.target

AllowIsolate=yes

[root@testvm1 system]#

El objetivo.predeterminado —que en realidad es un enlace al multi-user.target en este momento, ahora tiene diferentes requisitos en la [Unidad] sección. No requiere el administrador de visualización gráfica.

Reiniciar. Su máquina virtual debe iniciarse en el inicio de sesión de la consola para la consola virtual 1, que se identifica en la pantalla como tty1. Ahora que sabe cómo cambiar el objetivo predeterminado, vuelva a cambiarlo a graphical.target usando un comando diseñado para el propósito.

Primero, verifique el objetivo predeterminado actual:

[root@testvm1 ~]# systemctl get-default 

multi-user.target

[root@testvm1 ~]# systemctl set-default graphical.target

Removed /etc/systemd/system/default.target.

Created symlink /etc/systemd/system/default.target → /usr/lib/systemd/system/graphical.target.

[root@testvm1 ~]#

Introduzca el siguiente comando para ir directamente a graphical.target y la página de inicio de sesión del administrador de visualización sin tener que reiniciar:

[root@testvm1 system]# systemctl isolate default.target

No sé por qué los desarrolladores de systemd eligieron el término "aislar" para este subcomando. Mi investigación indica que puede referirse a ejecutar el objetivo especificado pero "aislar" y terminar todos los demás objetivos que no son necesarios para admitir el objetivo. Sin embargo, el efecto es cambiar los objetivos de un objetivo de ejecución a otro, en este caso, del objetivo multiusuario al objetivo gráfico. El comando anterior es equivalente al antiguo comando init 5 en los scripts de inicio de SystemV y el programa init.

Inicie sesión en el escritorio de la GUI y verifique que funcione como debería.

Resumiendo

Este artículo exploró la secuencia de inicio de systemd de Linux y comenzó a explorar dos herramientas systemd importantes, systemctl y diarioctl . También explicó cómo cambiar de un destino a otro y cambiar el destino predeterminado.

El siguiente artículo de esta serie creará una nueva unidad systemd y la configurará para que se ejecute durante el inicio. También analizará algunas de las opciones de configuración que ayudan a determinar en qué lugar de la secuencia se iniciará una unidad en particular, por ejemplo, después de que la red esté en funcionamiento.

Recursos

Hay una gran cantidad de información sobre systemd disponible en Internet, pero mucha es concisa, obtusa o incluso engañosa. Además de los recursos mencionados en este artículo, las siguientes páginas web ofrecen información más detallada y confiable sobre el inicio de systemd.

• El Proyecto Fedora tiene una buena guía práctica para systemd. Tiene prácticamente todo lo que necesita saber para configurar, administrar y mantener una computadora Fedora usando systemd.
• El Proyecto Fedora también tiene una buena hoja de trucos que hace una referencia cruzada de los comandos antiguos de SystemV con los de systemd comparables.
• Para obtener información técnica detallada sobre systemd y las razones para crearlo, consulte la descripción de systemd de Freedesktop.org.
• "More systemd fun" de Linux.com ofrece información y consejos más avanzados sobre systemd.

También hay una serie de artículos profundamente técnicos para administradores de sistemas Linux escritos por Lennart Poettering, el diseñador y desarrollador principal de systemd. Estos artículos fueron escritos entre abril de 2010 y septiembre de 2011, pero son tan relevantes ahora como lo fueron entonces. Gran parte de todo lo bueno que se ha escrito sobre systemd y su ecosistema se basa en estos documentos.

• Repensar el PID 1
• systemd para administradores, Parte I
• systemd para administradores, Parte II
• systemd para administradores, Parte III
• systemd para administradores, Parte IV
• systemd para administradores, Parte V
• systemd para administradores, Parte VI
• systemd para administradores, Parte VII
• systemd para administradores, Parte VIII
• systemd para administradores, Parte IX
• systemd para administradores, Parte X
• systemd para administradores, Parte XI