Aprendiendo a amar systemd

"En realidad, no tengo opiniones particularmente sólidas sobre systemd en sí. He tenido problemas con algunos de los principales desarrolladores que creo que son demasiado arrogantes con respecto a los errores y la compatibilidad, y creo que algunos de los detalles de diseño son una locura (yo no me gustan los registros binarios, por ejemplo), pero esos son detalles, no grandes problemas".

Por si no sabes mucho de Linus, te puedo decir que si algo no le gusta, es muy franco, explícito y bastante claro sobre ese disgusto. Se ha vuelto más aceptable socialmente en su forma de abordar su disgusto por las cosas.

En 2013, Poettering escribió una larga publicación de blog en la que desacredita los mitos sobre systemd y proporciona información sobre algunas de las razones para crearlo. Esta es una lectura muy buena y la recomiendo mucho.

tareas systemd

Dependiendo de las opciones utilizadas durante el proceso de compilación (que no se consideran en esta serie), systemd puede tener hasta 69 ejecutables binarios que realizan las siguientes tareas, entre otras:

• El programa systemd se ejecuta como PID 1 y proporciona el inicio del sistema de tantos servicios en paralelo como sea posible, lo que, como efecto secundario, acelera los tiempos de inicio generales. También gestiona la secuencia de apagado.
• El programa systemctl proporciona una interfaz de usuario para la gestión de servicios.
• Se ofrece soporte para scripts de inicio SystemV y LSB para compatibilidad con versiones anteriores.
• La gestión de servicios y los informes proporcionan más datos sobre el estado del servicio que SystemV.
• Incluye herramientas para la configuración básica del sistema, como nombre de host, fecha, configuración regional, listas de usuarios registrados, contenedores y máquinas virtuales en ejecución, cuentas del sistema, directorios y configuraciones de tiempo de ejecución, demonios para administrar la configuración de red simple, sincronización de tiempo de red , reenvío de registros y resolución de nombres.
• Ofrece administración de sockets.
• Los temporizadores de systemd brindan capacidades similares a las de cron para incluir la ejecución de un script en momentos relacionados con el inicio del sistema, el inicio de systemd, la última vez que se inició el temporizador y más.
• Proporciona una herramienta para analizar fechas y horas utilizadas en las especificaciones del temporizador.
• El montaje y desmontaje de sistemas de archivos con conciencia jerárquica permite una cascada más segura de sistemas de archivos montados.
• Permite la creación y gestión positiva de archivos temporales, incluida la eliminación.
• Una interfaz para D-Bus proporciona la capacidad de ejecutar secuencias de comandos cuando los dispositivos se conectan o desconectan. Esto permite que todos los dispositivos, ya sean enchufables o no, se traten como plug-and-play, lo que simplifica considerablemente el manejo del dispositivo.
• Su herramienta para analizar la secuencia de inicio se puede utilizar para localizar los servicios que toman más tiempo.
• Incluye diarios para almacenar mensajes de registro del sistema y herramientas para administrar los diarios.

Arquitectura

Esas tareas y más son compatibles con una serie de demonios, programas de control y archivos de configuración. La Figura 1 muestra muchos de los componentes que pertenecen a systemd. Este es un diagrama simplificado diseñado para proporcionar una descripción general de alto nivel, por lo que no incluye todos los programas o archivos individuales. Tampoco proporciona información sobre el flujo de datos, que es tan complejo que sería un ejercicio inútil en el contexto de esta serie de artículos.

Una exposición completa de systemd tomaría un libro por sí solo. No necesita comprender los detalles de cómo encajan los componentes de systemd en la Figura 1; es suficiente conocer los programas y componentes que permiten administrar varios servicios de Linux y manejar archivos de registro y diarios. Pero está claro que systemd no es la monstruosidad monolítica que pretenden ser algunos de sus críticos.

systemd como PID 1

systemd es PID 1. Algunas de sus funciones, que son mucho más extensas que el antiguo programa init SystemV3, son administrar muchos aspectos de un host Linux en ejecución, incluido el montaje de sistemas de archivos y el inicio y la administración de los servicios del sistema necesarios para tener un host Linux productivo. Cualquiera de las tareas de systemd que no están relacionadas con la secuencia de inicio están fuera del alcance de este artículo (pero algunas se explorarán más adelante en esta serie).

Primero, systemd monta los sistemas de archivos definidos por /etc/fstab , incluidos los archivos de intercambio o las particiones. En este punto, puede acceder a los archivos de configuración ubicados en /etc , incluido el propio. Utiliza su enlace de configuración, /etc/systemd/system/default.target , para determinar en qué estado u objetivo debe iniciar el host. 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 es similar al modo de usuario único. Los objetivos y los servicios son unidades systemd.

La siguiente tabla (Figura 2) compara los objetivos de systemd con los niveles de ejecución de inicio de SystemV anteriores. systemd proporciona los alias de destino de systemd para la compatibilidad con versiones anteriores. Los alias de destino permiten que los scripts, y muchos 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. En la Figura 2, los objetivos con la mayor funcionalidad se encuentran en la parte superior de la tabla, y la funcionalidad disminuye hacia la parte inferior de la tabla.

systemd también examina los directorios de inicio heredados de SystemV para ver si existen archivos de inicio allí. Si es así, systemd los usa como archivos de configuración para iniciar los servicios descritos por los archivos. El servicio de red en desuso es un buen ejemplo de uno que todavía usa los archivos de inicio de SystemV en Fedora.

La figura 3 (abajo) se copia directamente de la página del manual de arranque. Muestra un mapa de la secuencia general de eventos durante el inicio de systemd y los requisitos básicos de pedido para garantizar un inicio exitoso.

                                         cryptsetup-pre.target

                                                   |

 (various low-level                                v

     API VFS mounts:                 (various cryptsetup devices...)

  mqueue, configfs,                                |    |

  debugfs, ...)                                    v    |

  |                                  cryptsetup.target  |

  |  (various swap                                 |    |    remote-fs-pre.target

  |   devices...)                                  |    |     |        |

  |    |                                           |    |     |        v

  |    v                       local-fs-pre.target |    |     |  (network file systems)

  |  swap.target                       |           |    v     v                 |

  |    |                               v           |  remote-cryptsetup.target  |

  |    |  (various low-level  (various mounts and  |             |              |

  |    |   services: udevd,    fsck services...)   |             |    remote-fs.target

  |    |   tmpfiles, random            |           |             |             /

  |    |   seed, sysctl, ...)          v           |             |            /

  |    |      |                 local-fs.target    |             |           /

  |    |      |                        |           |             |          /

  \____|______|_______________   ______|___________/             |         /

                              \ /                                |        /

                               v                                 |       /

                        sysinit.target                           |      /

                               |                                 |     /

        ______________________/|\_____________________           |    /

       /              |        |      |               \          |   /

       |              |        |      |               |          |  /

       v              v        |      v               |          | /

  (various       (various      |  (various            |          |/

   timers...)      paths...)   |   sockets...)        |          |

       |              |        |      |               |          |

       v              v        |      v               |          |

 timers.target  paths.target   |  sockets.target      |          |

       |              |        |      |               v          |

       v              \_______ | _____/         rescue.service   |

                              \|/                     |          |

                               v                      v          |

                           basic.target         rescue.target    |

                               |                                 |

                       ________v____________________             |

                      /              |              \            |

                      |              |              |            |

                      v              v              v            |

                  display-    (various system   (various system  |

              manager.service     services        services)      |

                      |         required for        |            |

                      |        graphical UIs)       v            v

                      |              |            multi-user.target

 emergency.service    |              |              |

         |            \_____________ | _____________/

         v                          \|/

 emergency.target                    v

                              graphical.target

El sysinit.objetivo y objetivo.básico los objetivos pueden considerarse puntos de control en el proceso de inicio. Aunque uno de los objetivos de diseño de systemd es iniciar los servicios del sistema en paralelo, ciertos servicios y destinos funcionales deben iniciarse antes de que puedan iniciarse otros servicios y destinos. Estos puntos de control no se pueden pasar hasta que se cumplan todos los servicios y objetivos requeridos por ese punto de control.

El sysinit.objetivo se alcanza cuando se completan todas las unidades de las que depende. Todas esas unidades, montar sistemas de archivos, configurar archivos de intercambio, iniciar udev, configurar la semilla del generador aleatorio, iniciar servicios de bajo nivel y configurar servicios criptográficos (si uno o más sistemas de archivos están encriptados), deben completarse pero, dentro del sysinit.objetivo , esas tareas se pueden realizar en paralelo.

El sysinit.objetivo pone en marcha todos los servicios y unidades de bajo nivel necesarios para que el sistema sea marginalmente funcional y que se requieren para permitir pasar al basic.target .

Después de sysinit.target se cumple, systemd luego inicia todas las unidades requeridas para cumplir con el siguiente objetivo. El objetivo básico proporciona alguna funcionalidad adicional al iniciar las unidades que se requieren para todos los próximos objetivos. Estos incluyen configurar cosas como rutas a varios directorios ejecutables, sockets de comunicación y temporizadores.

Finalmente, los objetivos a nivel de usuario, multi-user.target o objetivo.gráfico , se puede inicializar. El objetivo.multiusuario debe alcanzarse antes de que se puedan cumplir las dependencias de destino gráficas. Los objetivos subrayados en la Figura 3 son los objetivos habituales de inicio. Cuando se alcanza uno de estos objetivos, el inicio se ha completado. Si el multiusuario.objetivo es el valor predeterminado, entonces debería ver un inicio de sesión en modo texto en la consola. Si objetivo.gráfico es el valor predeterminado, entonces debería ver un inicio de sesión gráfico; la pantalla de inicio de sesión GUI específica que ve depende de su administrador de visualización predeterminado.

La página del manual de arranque también describe y proporciona mapas del arranque en el disco RAM inicial y el proceso de apagado de systemd.

systemd también proporciona una herramienta que enumera las dependencias de un inicio completo o para una unidad específica. Una unidad es una entidad de recursos systemd controlable que puede abarcar desde un servicio específico, como httpd o sshd, hasta temporizadores, montajes, sockets y más. Pruebe el siguiente comando y desplácese por los resultados.

systemctl list-dependencies graphical.target

Tenga en cuenta que esto expande por completo la lista de unidades de destino de nivel superior requeridas para llevar el sistema al modo de ejecución de destino gráfico. Usa el --todos opción para expandir todas las otras unidades también.

systemctl list-dependencies --all graphical.target

Puede buscar cadenas como "target", "slice" y "socket" con las herramientas de búsqueda de menos comando.

Así que ahora, intente lo siguiente.

systemctl list-dependencies multi-user.target

y

systemctl list-dependencies rescue.target

y

systemctl list-dependencies local-fs.target

y

systemctl list-dependencies dbus.service

Esta herramienta me ayuda a visualizar los detalles de las dependencias de inicio para el host en el que estoy trabajando. Continúe y dedique un tiempo a explorar el árbol de inicio para uno o más de sus hosts Linux. Pero tenga cuidado porque la página man de systemctl contiene esta nota: