sistemad

sistemad

Inicio de systemd en Fedora 17
Autor(es) original(es)	Lennart Poettering [1]
Desarrollador(es)	Red Hat ( Lennart Poettering , Kay Sievers , Harald Hoyer , Daniel Mack, Tom Gundersen, David Herrmann); [2] 345 autores diferentes en 2018 [3] y 2.032 autores diferentes en total [4]
Lanzamiento inicial	30 de marzo de 2010 ; hace 14 años ( 30-03-2010 )
Versión estable	256.6 [5]  / 10 de septiembre de 2024
Repositorio	github.com/systemd/systemd
Escrito en	do
Sistema operativo	Linux
Tipo	Software del sistema Supervisor de procesos Gerente de servicio
Licencia	Licencia LGPLv2.1+ [6]
Sitio web	sistemad.io

systemd es una suite de software que proporciona una serie de componentes de sistema para sistemas operativos Linux ^[7] . El objetivo principal es unificar la configuración y el comportamiento de los servicios en todas las distribuciones de Linux . ^[8] Su componente principal es un "administrador de sistemas y servicios", un sistema de inicio utilizado para arrancar el espacio de usuario y administrar los procesos de usuario . También proporciona reemplazos para varios daemons y utilidades, incluida la administración de dispositivos, la administración de inicio de sesión, la administración de conexiones de red y el registro de eventos. El nombre systemd se adhiere a la convención Unix de nombrar daemons agregando la letra d . ^[9] También juega con el término " System D ", que se refiere a la capacidad de una persona para adaptarse rápidamente e improvisar para resolver problemas. ^[10]

Desde 2015, la mayoría de las distribuciones de Linux han adoptado systemd, habiendo reemplazado otros sistemas de inicio como SysV init . Ha sido elogiado por los desarrolladores y usuarios de las distribuciones que lo adoptaron por proporcionar una solución estable, rápida y lista para usar para problemas que habían existido en el espacio Linux durante años. ^{[11] [12] [13]} En el momento de la adopción de systemd en la mayoría de las distribuciones de Linux, era la única suite de software que ofrecía un paralelismo confiable durante el arranque, así como una gestión centralizada de procesos , daemons, servicios y puntos de montaje .

Los críticos de systemd sostienen que sufre de expansión de la misión y de hinchazón , esta última afectando a otro software (como el escritorio GNOME ), añadiendo dependencias en systemd, reduciendo su compatibilidad con otros sistemas operativos tipo Unix y dificultando a los administradores de sistemas la integración de soluciones alternativas. Además, sostienen que la complejidad de systemd da como resultado una mayor superficie de ataque , lo que reduce la seguridad general de la plataforma. ^[14] También se han planteado preocupaciones sobre Red Hat y su empresa matriz IBM controlando la escena de los sistemas init en Linux. ^{[15] [1]}

Lennart Poettering y Kay Sievers , los ingenieros de software que trabajaban en Red Hat y que inicialmente desarrollaron systemd, ^[2] comenzaron un proyecto para reemplazar el init convencional de Linux, System V, en 2010. ^[16] Una publicación de blog de abril de 2010 de Poettering, titulada "Rethinking PID 1", presentó una versión experimental de lo que luego se convertiría en systemd. ^[17] Buscaban superar la eficiencia del demonio init de varias maneras. Querían mejorar el marco de software para expresar dependencias, permitir que se realicen más procesos de manera concurrente o en paralelo durante el arranque del sistema y reducir la sobrecarga computacional del shell .

En mayo de 2011, Fedora Linux se convirtió en la primera distribución Linux importante en habilitar systemd de forma predeterminada, reemplazando a Upstart . El razonamiento en ese momento fue que systemd brindaba una amplia paralelización durante el inicio, una mejor gestión de los procesos y, en general, un enfoque más sensato y basado en dependencias para controlar el sistema. ^[18]

En octubre de 2012, Arch Linux convirtió a systemd en el predeterminado, reemplazando a SysVinit . ^[19] Los desarrolladores habían debatido desde agosto de 2012 ^[13] y llegaron a la conclusión de que era más rápido y tenía más funciones que SysVinit, y que mantener este último no valía la pena el esfuerzo en parches. ^[20] Algunos de ellos pensaron que las críticas hacia la implementación de systemd no se basaban en deficiencias reales del software, sino en el desagrado de Lennart por parte de una parte de la comunidad Linux y la vacilación general por el cambio. Específicamente, algunas de las quejas sobre que systemd no estaba programado en bash, que era más grande y más extenso que SysVinit, el uso de D-bus y el formato opcional en disco del diario fueron consideradas como ventajas por los programadores. ^[21]

Entre octubre de 2013 y febrero de 2014, se produjo un largo debate en el Comité Técnico de Debian en la lista de correo de Debian , ^[22] discutiendo qué sistema de inicio utilizar como predeterminado en Debian 8 "jessie", y que culminó en una decisión a favor de systemd. El debate fue ampliamente publicitado ^{[23] [24]} y a raíz de la decisión el debate continúa en la lista de correo de Debian. En febrero de 2014, después de que se tomara la decisión de Debian, Mark Shuttleworth anunció en su blog que Ubuntu seguiría en la implementación de systemd, descartando su propio Upstart . ^{[25] [26]}

En noviembre de 2014, el desarrollador de Debian Joey Hess ^[27], los miembros del Comité Técnico de Debian Russ Allbery ^[28] e Ian Jackson [ ^29] y el encargado del mantenimiento del paquete systemd Tollef Fog Heen ^[30] renunciaron a sus cargos. Los cuatro justificaron su decisión en la lista de correo pública de Debian y en blogs personales con su exposición a niveles de estrés extraordinarios relacionados con las disputas en curso sobre la integración de systemd dentro de la comunidad Debian y FOSS que hicieron que el mantenimiento regular fuera virtualmente imposible.

En agosto de 2015, systemd comenzó a proporcionar un shell de inicio de sesión, al que se puede llamar a través de machinectl shell. ^[31]

En septiembre de 2016, se descubrió un error de seguridad que permitía a cualquier usuario sin privilegios realizar un ataque de denegación de servicio contra systemd. ^[32] Rich Felker, desarrollador de musl , afirmó que este error revela una importante "falla de diseño de desarrollo del sistema". ^[33] En 2017 se descubrió otro error de seguridad en systemd, CVE - 2017-9445, que "permite la interrupción del servicio" por un "servidor DNS malicioso". ^{[34] [35]} Más tarde en 2017, los Premios Pwnie le dieron al autor Lennart Poettering un premio a la "respuesta más floja del proveedor" debido a su manejo de las vulnerabilidades. ^[36]

Poettering describe el desarrollo de systemd como "nunca terminado, nunca completo, pero que sigue el progreso de la tecnología". En mayo de 2014, Poettering describió además systemd como unificador de "diferencias sin sentido entre distribuciones", al proporcionar las siguientes tres funciones generales: ^[39]

• Un administrador de sistemas y servicios (administra tanto el sistema, mediante la aplicación de diversas configuraciones, como sus servicios)
• Una plataforma de software (sirve como base para desarrollar otro software)
• El pegamento entre las aplicaciones y el kernel (proporciona varias interfaces que exponen funcionalidades proporcionadas por el kernel)

systemd incluye características como el inicio bajo demanda de daemons, soporte de instantáneas, seguimiento de procesos ^[40] y bloqueos de inhibidores. ^[41] No es solo el nombre del daemon init sino que también se refiere a todo el paquete de software a su alrededor, que, además del daemon init systemd , incluye los daemons journald , logind y networkd , y muchos otros componentes de bajo nivel. En enero de 2013, Poettering describió systemd no como un programa, sino como una gran suite de software que incluye 69 binarios individuales. ^[42] Como una suite de software integrada , systemd reemplaza las secuencias de inicio y los niveles de ejecución controlados por el daemon init tradicional, junto con los scripts de shell ejecutados bajo su control. systemd también integra muchos otros servicios que son comunes en los sistemas Linux al manejar los inicios de sesión de los usuarios, la consola del sistema , la conexión en caliente de dispositivos (ver udev ), la ejecución programada (reemplazando a cron ), el registro, los nombres de host y las configuraciones regionales.

Al igual que el demonio init, systemd es un demonio que administra otros demonios, que, incluido el propio systemd , son procesos en segundo plano . systemd es el primer demonio que se inicia durante el arranque y el último que finaliza durante el apagado . El demonio systemd sirve como raíz del árbol de procesos del espacio de usuario ; el primer proceso ( PID 1) tiene un papel especial en los sistemas Unix, ya que reemplaza al padre de un proceso cuando el padre original finaliza. Por lo tanto, el primer proceso es particularmente adecuado para el propósito de monitorear demonios.

systemd ejecuta elementos de su secuencia de inicio en paralelo, lo que teóricamente es más rápido que el enfoque de secuencia de inicio tradicional. ^[43] Para la comunicación entre procesos (IPC), systemd pone los sockets de dominio Unix y D-Bus a disposición de los daemons en ejecución. El estado de systemd en sí también se puede conservar en una instantánea para su posterior recuperación.

Siguiendo su enfoque integrado, systemd también proporciona reemplazos para varios daemons y utilidades, incluidos los scripts de shell de inicio, pm-utils, inetd , acpid , syslog , watchdog, cron y atd . Los componentes principales de systemd incluyen los siguientes:

• systemd es un administrador de sistemas y servicios para sistemas operativos Linux.
• systemctl es un comando para introspeccionar y controlar el estado del sistema systemd y el administrador de servicios. No debe confundirse con sysctl .
• systemd-analyze se puede utilizar para determinar estadísticas de rendimiento de arranque del sistema y recuperar otra información de estado y seguimiento del administrador del sistema y de servicios.

systemd rastrea procesos usando el subsistema cgroups del kernel de Linux en lugar de usar identificadores de proceso (PIDs); por lo tanto, los daemons no pueden "escapar" de systemd , ni siquiera mediante una doble bifurcación . systemd no solo usa cgroups, sino que también los aumenta con systemd-nspawn y machinectl , dos programas de utilidad que facilitan la creación y administración de contenedores de Linux . ^[44] Desde la versión 205, systemd también ofrece ControlGroupInterface, que es una API para los cgroups del kernel de Linux. ^[45] Los cgroups del kernel de Linux están adaptados para soportar kernfs , ^[46] y están siendo modificados para soportar una jerarquía unificada. ^[47]

Además de su propósito principal de proporcionar un sistema de inicio de Linux, la suite systemd puede proporcionar funcionalidad adicional, incluidos los siguientes componentes:

diario

systemd-journald es un demonio responsable del registro de eventos , con archivos binarios de solo anexión que sirven como archivos de registro . El administrador del sistema puede elegir si registrar eventos del sistema con systemd-journald , syslog-ng o rsyslog . El potencial de corrupción del formato binario ha dado lugar a un acalorado debate. ^[48]

libudev

libudev es la biblioteca estándar para utilizar udev, que permite que aplicaciones de terceros consulten recursos de udev.

localizado

localed administra la configuración regional del sistema y la distribución del teclado .

iniciar sesión

systemd-logind es un demonio que administra los inicios de sesión y los asientos de los usuarios de varias maneras. Es un administrador de inicio de sesión integrado que ofrece mejoras para múltiples asientos ^[49] y reemplaza a ConsoleKit , que ya no se mantiene. ^[50] Para los administradores de pantalla X11, el cambio a logind requiere una cantidad mínima de portabilidad. ^[51] Se integró en la versión 30 de systemd.

nombre de host

hostnamed administra el nombre de host del sistema .

alojado

homed es un demonio que proporciona cuentas de usuario humano portátiles que son independientes de la configuración actual del sistema. homed mueve varias piezas de datos como UID/GID desde varios lugares a través del sistema de archivos a un solo archivo. homed administra el directorio de inicio del usuario de varias maneras, como un directorio simple, un subvolumen btrfs , un volumen de configuración de clave unificada de Linux , un directorio fscrypt o montado desde un servidor SMB .~/.identity

en red

networkd es un demonio que se encarga de la configuración de las interfaces de red; en la versión 209, cuando se integró por primera vez, el soporte se limitaba a direcciones asignadas estáticamente y soporte básico para configuración de puentes . ^{[52] [53] [54] [55] [56]} En julio de 2014, se lanzó la versión 215 de systemd, que agregó nuevas características como un servidor DHCP para hosts IPv4 y soporte VXLAN . ^{[57] [58]} networkctl se puede usar para revisar el estado de los enlaces de red como los ve systemd-networkd. ^[59] La configuración de nuevas interfaces se debe agregar en /lib/systemd/network/ como un nuevo archivo que termina con la extensión .network.

resuelto

Proporciona resolución de nombres de red a aplicaciones locales

arranque del sistema

systemd-boot es un gestor de arranque, anteriormente conocido como gummiboot . Kay Sievers lo fusionó con systemd en la versión 220.

error BSOD del sistema

systemd-bsod es un reportero de errores utilizado para generar la Pantalla Azul de la Muerte .

sistemad-nspawn

systemd-nspawn se puede usar para ejecutar un comando o sistema operativo en un contenedor de espacio de nombres.

con fecha de caducidad

systemd-timedated es un demonio que se puede utilizar para controlar configuraciones relacionadas con el tiempo, como la hora del sistema, la zona horaria del sistema o la selección entre UTC y el reloj del sistema de la zona horaria local. Se puede acceder a él a través de D-Bus. ^[60] Se integró en la versión 30 de systemd.

sincronización horaria

timesyncd es un demonio NTP cliente para sincronizar el reloj del sistema a través de la red.

archivos temporales

systemd-tmpfiles es una utilidad que se encarga de la creación y limpieza de archivos y directorios temporales. Normalmente se ejecuta una vez al inicio y luego en intervalos específicos.

Desaparecido

udev es un administrador de dispositivos para el núcleo Linux , que maneja el directorio /dev y todas las acciones del espacio de usuario al agregar o quitar dispositivos, incluida la carga de firmware . En abril de 2012, el árbol de código fuente de udev se fusionó con el árbol de código fuente de systemd. ^{[61] [62]} Para que coincida con el número de versión de udev, los mantenedores de systemd aumentaron el número de versión directamente de 44 a 183. ^[63]

El 29 de mayo de 2014, se eliminó el soporte para la carga de firmware a través de udev de systemd, ya que se decidió que el kernel debería ser responsable de cargar el firmware. ^[64]

systemd se configura exclusivamente a través de archivos de texto sin formato .

systemd registra las instrucciones de inicialización para cada demonio en un archivo de configuración (denominado "archivo de unidad") que utiliza un lenguaje declarativo , reemplazando los scripts de shell de inicio por demonio que se utilizan tradicionalmente . La sintaxis del lenguaje está inspirada en los archivos .ini . ^[65]

Los tipos de archivos unitarios ^[66] incluyen:

• .servicio
• .enchufe
• .device (iniciado automáticamente por systemd ^[67] )
• .montar
• .montaje automático
• .intercambio
• .objetivo
• .camino
• .timer (que puede utilizarse como un programador de tareas tipo cron ^[68] )
• .instantánea
• .slice (se utiliza para agrupar y gestionar procesos y recursos ^[69] )
• .scope (se utiliza para agrupar procesos de trabajo, no está pensado para configurarse mediante archivos de unidad ^[70] )

Aunque muchas distribuciones arrancan systemd de forma predeterminada, algunas permiten utilizar otros sistemas de inicio; en este caso, es posible cambiar el sistema de inicio instalando los paquetes adecuados. Se desarrolló una bifurcación de Debian llamada Devuan para evitar systemd ^{[98] [99]} y ha alcanzado la versión 5.0 para uso estable. En diciembre de 2019, el proyecto Debian votó a favor de mantener systemd como el sistema de inicio predeterminado para la distribución, pero con soporte para "explorar alternativas". ^[100]

Con el objetivo de mejorar la interoperabilidad entre systemd y el entorno de escritorio GNOME , el coautor de systemd, Lennart Poettering, solicitó al Proyecto GNOME que considerara convertir a systemd en una dependencia externa de GNOME 3.2. ^[101]

En noviembre de 2012, el Proyecto GNOME concluyó que la funcionalidad básica de GNOME no debería depender de systemd. ^[102] Sin embargo, GNOME 3.8 introdujo una opción en tiempo de compilación entre logind y ConsoleKit API, siendo la primera proporcionada en ese momento solo por systemd. Ubuntu proporcionó un binario logind separado, pero systemd se convirtió en una dependencia de facto de GNOME para la mayoría de las distribuciones de Linux , en particular porque ConsoleKit ya no se mantiene activamente y upstream recomienda el uso de systemd-logind en su lugar. ^[103] Los desarrolladores de Gentoo Linux también intentaron adaptar estos cambios en OpenRC , pero la implementación contenía demasiados errores, lo que provocó que la distribución marcara systemd como una dependencia de GNOME. ^{[104] [105]}

GNOME ha integrado aún más logind . ^[106] A partir de la versión 3.13.2 de Mutter , logind es una dependencia para las sesiones de Wayland . ^[107]

El diseño de systemd ha generado controversia dentro de la comunidad de software libre . Los críticos consideran que systemd es demasiado complejo y sufre un continuo aumento de características , argumentando que su arquitectura viola la filosofía Unix . También existe la preocupación de que forme un sistema de dependencias interconectadas, lo que da a los mantenedores de distribuciones pocas opciones más que adoptar systemd a medida que más software de espacio de usuario pasa a depender de sus componentes, lo que es similar a los problemas creados por PulseAudio , otro de los proyectos de Lennart Poettering. ^{[108] [109]}

En una entrevista de 2012, el líder de Slackware, Patrick Volkerding, expresó reservas sobre la arquitectura systemd, afirmando que creía que su diseño era contrario a la filosofía Unix de utilidades interconectadas con funcionalidades estrechamente definidas. ^[110] A agosto de 2018 ^[actualizar], Slackware no admite ni usa systemd, pero Volkerding no ha descartado la posibilidad de cambiarlo. ^[111]

En enero de 2013, Lennart Poettering intentó abordar las preocupaciones sobre systemd en una publicación de blog llamada The Biggest Myths . ^[42]

En febrero de 2014, Rich Felker de musl opinó que PID 1 es demasiado especial como para cargarlo con responsabilidades adicionales, creyendo que PID 1 solo debería ser responsable de iniciar el resto del sistema init y eliminar los procesos zombies , y que la funcionalidad adicional agregada por systemd se puede proporcionar en otro lugar y aumenta innecesariamente la complejidad y la superficie de ataque de PID 1. ^[112]

En marzo de 2014, Eric S. Raymond comentó que los objetivos de diseño de systemd eran propensos a la expansión de la misión y la hinchazón del software . ^[113] En abril de 2014, Linus Torvalds expresó reservas sobre la actitud de Kay Sievers , un desarrollador clave de systemd, hacia los usuarios y los informes de errores con respecto a las modificaciones al núcleo de Linux enviadas por Sievers. ^[114] A fines de abril de 2014, se lanzó una campaña para boicotear systemd, con un sitio web que enumeraba varias razones en contra de su adopción. ^{[115] [116]}

En un artículo de agosto de 2014 publicado en InfoWorld , Paul Venezia escribió sobre la controversia de systemd y atribuyó la controversia a la violación de la filosofía Unix y a "enormes egos que creen firmemente que no pueden hacer nada malo". ^[117] El artículo también caracteriza la arquitectura de systemd como similar a la de svchost.exe , un componente crítico del sistema en Microsoft Windows con un amplio alcance funcional. ^[117]

En una entrevista de ZDNet en septiembre de 2014 , el destacado desarrollador del núcleo Linux Theodore Ts'o expresó su opinión de que la disputa sobre la filosofía de diseño centralizada de systemd, más que preocupaciones técnicas, indica una peligrosa tendencia general hacia la uniformización del ecosistema Linux, alienando y marginando partes de la comunidad de código abierto y dejando poco espacio para proyectos alternativos. Citó similitudes con la actitud que encontró en el proyecto GNOME hacia las configuraciones no estándar. ^[118] En las redes sociales, Ts'o también comparó más tarde las actitudes de Sievers y su codesarrollador, Lennart Poettering, con la de los desarrolladores de GNOME. ^[119]

Las bifurcaciones de systemd están estrechamente vinculadas a las críticas que se han hecho al respecto en la sección anterior. Las bifurcaciones generalmente intentan mejorar al menos uno de los aspectos: portabilidad (a otras bibliotecas y sistemas tipo Unix), modularidad o tamaño. Unas pocas bifurcaciones han colaborado bajo el nombre de FreeInit. ^[120]

En 2012, el proyecto Gentoo Linux creó una bifurcación de udev para evitar la dependencia de la arquitectura systemd. La bifurcación resultante se llama eudev y hace que la funcionalidad de udev esté disponible sin systemd. ^[121] Un objetivo declarado del proyecto es mantener a eudev independiente de cualquier distribución de Linux o sistema de inicio. ^[122] En 2021, Gentoo anunció que el soporte de eudev cesaría a principios de 2022. Desde entonces, un grupo independiente de mantenedores se ha hecho cargo de eudev. ^[123]

Elogind es el "logind" del proyecto systemd, extraído para ser un demonio independiente. Se integra con PAM para conocer el conjunto de usuarios que están conectados a un sistema y si lo están de forma gráfica, en la consola o de forma remota. Elogind expone esta información a través de la interfaz D-Bus estándar org.freedesktop.login1 , así como a través del sistema de archivos utilizando el diseño estándar /run/systemd de systemd. Elogind también proporciona "libelogind", que es un subconjunto de las funciones ofrecidas por "libsystemd". También hay un archivo pkg-config "libelogind.pc". ^[124]

ConsoleKit fue bifurcado en octubre de 2014 por los desarrolladores de Xfce que querían que sus características se mantuvieran y estuvieran disponibles en sistemas operativos distintos de Linux. Si bien no descarta la posibilidad de revivir el repositorio original a largo plazo, el desarrollador principal considera que ConsoleKit2 es una necesidad temporal hasta que SystemBSD madure. ^[125]

LoginKit fue un intento de implementar un shim logind (systemd-logind) , que permitiría que los paquetes que dependen de systemd-logind funcionen sin depender de un sistema de inicio específico. ^[126] El proyecto ha estado inactivo desde febrero de 2015. ^[127]

En 2014, se inició un proyecto de Google Summer of Code llamado "systembsd" con el fin de proporcionar implementaciones alternativas de estas API para OpenBSD . El desarrollador original del proyecto lo inició con el fin de facilitar su transición de Linux a OpenBSD. ^[128] El desarrollo del proyecto finalizó en julio de 2016. ^[129]

El proyecto systembsd no proporcionó un reemplazo de init, sino que apuntó a proporcionar a OpenBSD demonios compatibles con hostnamed , timedated , localed y logind . El proyecto no creó una nueva funcionalidad similar a systemd, y sólo estaba destinado a actuar como un contenedor sobre el sistema nativo OpenBSD. El desarrollador pretendía que systembsd fuera instalable como parte de la colección de ports , no como parte de un sistema base, afirmando que "systemd y *BSD difieren fundamentalmente en términos de filosofía y prácticas de desarrollo". ^[128]

Notsystemd pretende implementar todas las características de systemd en cualquier sistema de inicio. ^[130] Fue creado por los desarrolladores de Parabola GNU/Linux-libre para crear paquetes con sus herramientas de desarrollo sin la necesidad de tener instalado systemd para ejecutar systemd-nspawn. El desarrollo cesó en julio de 2018. ^[131]

En 2014, se creó uselessd como una bifurcación ligera de systemd. El proyecto buscaba eliminar funciones y programas considerados innecesarios para un sistema de inicio, así como solucionar otros fallos percibidos. ^[132] El desarrollo del proyecto se detuvo en enero de 2015. ^[133]

uselessd soportaba las bibliotecas musl y μClibc , por lo que puede haber sido utilizado en sistemas integrados , mientras que systemd solo soporta glibc . El proyecto uselessd había planeado mejoras adicionales en la compatibilidad entre plataformas, así como revisiones arquitectónicas y refactorizaciones para la compilación de Linux en el futuro. ^[134]

InitWare es una refactorización modular de systemd, que traslada el sistema a plataformas BSD sin necesidad de glibc o llamadas al sistema específicas de Linux. Se sabe que funciona en DragonFly BSD, FreeBSD, NetBSD y GNU/Linux. Los componentes que se consideran innecesarios se eliminan. ^[135]

• Caja ocupada
• lanzamiento
• Distribuciones de Linux sin systemd
• Gestión de servicios del sistema operativo
• lectura anticipada
• correlo
• Instalación de gestión de servicios
• Pastor de demonios de GNU
• Advenedizo
• svchost.exe

• Sitio web oficial
• Systemd en GitHub
• Repensando el PID 1