systemd

systemd es un conjunto de demonios o daemons de administración de sistema, bibliotecas y herramientas diseñados como una plataforma de administración y configuración central para interactuar con el núcleo del Sistema operativo GNU/Linux. Descrito por sus autores como un "bloque de construcción básico" para un sistema operativo,[4] systemd se puede utilizar como un sistema de inicio de Linux (el proceso init llamado por el núcleo o kernel de Linux para inicializar el espacio de usuario durante el proceso de arranque de Linux y gestionar posteriormente todos los demás procesos). El nombre systemd se adhiere a la convención Unix de distinguir los demonios fácilmente por tener la letra d como la última letra del nombre de archivo.[5][6]

systemd

Inicio de systemd en Fedora 17
Información general
Tipo de programa Demonio de inicio (Init)
Autor Lennart Poettering, Kay Sievers[1]
Desarrollador Lennart Poettering, Kay Sievers y otros
Lanzamiento inicial 30 de abril de 2010
Licencia GNU LGPL 2.1+ (software libre)[2]
Información técnica
Programado en C[3]
Versiones
Última versión estable 254.5 (info) ( 27 de septiembre de 2023 ())
Lanzamientos
Init
systemd
Enlaces

Se desarrolló systemd para reemplazar el sistema de inicio (init) heredado de los sistemas operativos estilo UNIX System V y Berkeley Software Distribution (BSD). En el proceso de arranque en Linux, es el primer proceso que se ejecuta en el espacio de usuario, por lo tanto, también es el proceso padre de todos los procesos hijos en el espacio de usuario. systemd se diseñó para el núcleo Linux y programado exclusivamente para la API de Linux. Escrito por Lennart Poettering[1] y se publica como software libre y de código abierto bajo los términos de la GNU General Public License (LGPL) versión 2.1 o posterior.[7] Uno de los principales objetivos de systemd es unificar configuraciones básicas de Linux y los comportamientos de servicios en todas las distribuciones.[8]

La idea de diseño está pensada en proveer un framework que exprese las dependencias del servicio con la API de Linux, permite hacer más trabajo paralelamente al inicio del sistema y reducir la sobrecarga del shell.

Hacia 2015, la mayoría de las principales distribuciones de Linux han adoptado systemd como su sistema de inicio predeterminado.

Diseño

La arquitectura de systemd como se utiliza por Tizen. Bastantes componentes, incluyendo a telephony, bootmode, dlog y tizen service, vienen de Tizen y no son componentes de systemd.[9]
Los cgroups de jerarquía unificada serán accesibles exclusivamente por systemd a través de systemd-nspawn[cita requerida]

Lennart Poettering y Kay Sievers, los ingenieros de software quienes originalmente diseñaron y desarrollaron systemd,[10] buscaron superar la eficiencia del demonio de inicio de diferentes maneras. Querían mejorar el framework para expresar dependencias, permitir que se realizara más procesamiento en concurrencia o en paralelo durante el arranque (booting) del sistema y reducir el overhead del shell.

Poettering describe el desarrollo de systemd como una "tecnología nunca terminada, nunca completa, pero que rastrea el progreso en tecnología". En mayo de 2014, Poettering definió a systemd más profundamente con el objetivo de unificar "diferencias sin sentido entre distribuciones", al proporcionar las siguientes tres funciones generales:[11]

  • Un administrador de sistema y de servicios (que gestiona tanto el sistema, tal como mediante la aplicación de varias configuraciones, como a sus servicios).[12]
  • Una plataforma de desarrollo de software (que sirve como base para el desarrollo de otros programas).
  • Una conexión entre las aplicaciones y el núcleo Linux (que ofrece diversas interfaces que exponen funcionalidades proporcionadas por el núcleo).

systemd es mucho más que el nombre del demonio de inicio, sino también se refiere al paquete de software completo alrededor de él, el cual, además del demonio init systemd, incluye a los daemons journald, logind y networkd, junto a otros componentes de bajo nivel. En enero de 2013, Poettering describió a systemd, no como a otro programa, sino como una suite de aplicaciones que incluye 69 binarios individuales.[13] Como paquete integral de software, systemd remplaza a la secuencia de arranque de Linux y los niveles de ejecución controlados por el demonio de inicio tradicional , junto con la ejecución de scripts de shell bajo su control. systemd también integra a muchos otros servicios que son comunes en sistemas de Linux manejando entradas de usuario, la interfaz de línea de comandos, la conexión en caliente de dispositivos (véase udev), registro de ejecución programada (remplazando a cron), hostname y configuraciones regionales.

Comparado con el init de System V, systemd puede tomar ventaja de nuevas técnicas:

  • Los servicios de activación de sockets y la activación de buses, que conduce a una mejor paralelización de servicios independientes.
  • cgroups se utilizan para realizar un seguimiento de los procesos de servicio, en lugar de PIDs. Esto significa que los demonios no pueden “escapar” de systemd aunque estén doblemente-bifurcados.

systemd es sólo para Linux por diseño, ya que depende de características como cgroups y fanotify.[14]

Adopción

En mayo de 2011, Fedora se convirtió en la primera distribución principal de Linux en habilitar systemd por defecto.[15]

Distribuciones en las que systemd está habilitado de forma predeterminada:

Distribuciones en las que systemd está disponible:

  • Gentoo ofrece paquetes systemd como elementos no soportados oficialmente.[25][26]

Utilización básica de systemctl

La principal orden usada para conocer y controlar systemd es systemctl. Algunos de los posibles usos son el examen del estado del sistema y la gestión del sistema o de los servicios.[27]

Analizar el estado del sistema

Para mostrar el estado del sistema utilice:

$ systemctl status

Para listar unidades en ejecución:

$ systemctl

o:

$ systemctl list-units

Para listar unidades que han fallado:

$ systemctl --failed

Puede ver un listado de las unidades instaladas con:

$ systemctl list-unit-files

Utilizar las unidades

Las unidades pueden ser, por ejemplo, services (.service), mount points (.mount), devices (.device) o sockets (.socket).

Cuando se usa systemctl, por lo general, tiene que especificar el nombre completo de la unidad, incluyendo el sufijo. Sin embargo, hay unos pocos atajos cuando se especifica la unidad en las siguientes órdenes systemctl:

  • Si no se especifica el sufijo, systemctl asumirá que es .service.
  • Los puntos de montaje se traducirán automáticamente en la correspondiente unidad .mount.
  • Similar a los puntos de montaje, los dispositivos se traducen automáticamente en la correspondiente unidad .device.

Activa una unidad de inmediato:

# systemctl start unidad

Detiene una unidad de inmediato:

# systemctl stop unidad

Reinicia la unidad:

# systemctl restart unidad

Hace que una unidad recargue su configuración:

# systemctl reload unidad

Muestra el estado de una unidad, incluso si se está ejecutando o no:

$ systemctl status unidad

Comprueba si la unidad ya está activada o no:

$ systemctl is-enabled unidad

Activa una unidad para iniciarse en el arranque:

# systemctl enable unidad

Activa una unidad para iniciarse en el arranque y lo inicia inmediatamente:

# systemctl enable --now unidad

Desactiva el inicio automático durante el arranque:

# systemctl disable unidad

Enmascara una unidad para que sea imposible iniciarla (tanto de forma manual como de dependencia, lo que hace que el enmascaramiento sea peligroso):

# systemctl mask unidad

Desenmascara una unidad:

# systemctl unmask unidad

Muestre la página del manual asociada a una unidad (esto debe ser compatible con el archivo de la unidad):

 $ systemctl help unidad

Recarga la configuración de systemd, buscando unidades nuevas o modificadas:

# systemctl daemon-reload

Gestionar la energía

Apagado y reinicio del sistema:

$ systemctl reboot

Apagado del sistema:

$ systemctl poweroff

Suspensión del sistema:

$ systemctl suspend

Poner el sistema en hibernación:

$ systemctl hibernate

Poner el sistema en estado de reposo híbrido —«hybrid-sleep» — (o suspensión combinada —«suspend-to-both»—):

$ systemctl hybrid-sleep

Críticas

Su implementación ha generado gran controversia dentro de la comunidad del software libre. Los críticos argumentan en al menos dos niveles:[28]

1. Arquitectura interna:

  • Critican que systemd ya es demasiado complejo y que sufre de una continua invasión de nuevas características.[29]
  • Además, le objetan que su arquitectura viola los principios de diseño de los sistemas operativos tipo Unix.

2. Implementación futura:

  • También existe la preocupación de que se torne en un sistema de dependencias entrelazadas, obligando así a los mantenedores de distribuciones a no tener más remedio que adoptar systemd a medida que más piezas de software del espacio de usuario sigan dependiendo de sus componentes.[30]

Véase también

Referencias

  1. Lennart Poettering. «FAQs». systemd. 0pointer. Consultado el 16 de junio de 2011.
  2. «GNU LGPL 2.1». gnu.org.
  3. «systemd», Analysis Summary (Ohloh), consultado el 16 de junio de 2011.
  4. Lennart Poettering (septiembre de 2010). «Beyond Init: systemd (LinuxKongress 2010)». Consultado el 28 de octubre de 2014.
  5. Lennart Poettering, Kay Sievers, Thorsten Leemhuis (8 de mayo de 2012), Control Centre: The systemd Linux init system, The H, archivado desde el original el 14 de octubre de 2012, consultado el 9 de septiembre de 2012.
  6. «systemd System and Service Manager» [systemd: administrador de sistema y servicios] (html). freedesktop.org (en inglés). 12 de junio de 2020. Archivado desde el original el 15 de octubre de 2020. Consultado el 20 de octubre de 2020. «Yes, it is written systemd, not system D or System D, or even SystemD. And it isn't system d either. Why? Because it's a system daemon, and under Unix/Linux those are in lower case, and get suffixed with a lower case d. And since systemd manages the system, it's called systemd. It's that simple. »
  7. Lennart Poettering (21 de abril de 2012). «systemd Status Update». Consultado el 28 de abril de 2012.
  8. «InterfaceStabilityPromise». freedesktop.org.
  9. Gundersen, Tom E. (25 de septiembre de 2014). «The End of Linux». Consultado el 25 de octubre de 2014. «It certainly is not something that comes with systemd from upstream. »
  10. «systemd README», freedesktop.org, consultado el 9 de septiembre de 2012.
  11. Poettering, Lennart (mayo de 2014). «A Perspective for systemd: What Has Been Achieved, and What Lies Ahead». Consultado el 30 de noviembre de 2014.
  12. «Detener, iniciar y reiniciar servicios en Linux.».
  13. Poettering, Lennart (26 de enero de 2013). «The Biggest Myths».
  14. Lennart Poettering (30 de abril de 2010), systemd FAQ, consultado el 14 de diciembre de 2011.
  15. "F15 one page release notes", fedoraproject.org, 2001-05-24
  16. Debian Project, Debian 8 "Jessie" released, Debian Project.
  17. Dj Walker-Morgan (24 de mayo de 2011), Fedora 15's Lovelock released, The H, archivado desde el original el 12 de julio de 2012, consultado el 26 de mayo de 2011.
  18. Phayz (17 de enero de 2012), Review of 2011, Frugalware Project, consultado el 22 de agosto de 2012.
  19. Fabian Scherschel (23 de mayo de 2012), Mageia 2 arrives with GNOME 3 and systemd, The H, archivado desde el original el 8 de diciembre de 2013, consultado el 26 de mayo de 2012.
  20. Dj Walker-Morgan (29 de agosto de 2011), Mandriva 2011 arrives with systemd, The H, archivado desde el original el 9 de julio de 2012, consultado el 29 de agosto de 2011.
  21. Chris von Eitzen (16 de noviembre de 2011), openSUSE 12.1 arrives with systemd and Btrfs, The H, archivado desde el original el 20 de abril de 2012, consultado el 16 de noviembre de 2011.
  22. systemd is now the default on new installations, Arch Linux News, 13 de octubre de 2012, consultado el 29 de octubre de 2012.
  23. http://news.siduction.org/2013/12/siduction-2013-2-rc1-released-with-systemd/
  24. «Chapter 9. Managing Services with systemd - Red Hat Customer Portal». access.redhat.com (en inglés). Consultado el 8 de diciembre de 2017.
  25. «Comment #210», systemd – bug #318365 (Gentoo's Bugzilla), consultado el 5 de julio de 2011.
  26. systemd, Gentoo's Documentation, consultado el 5 de julio de 2011.
  27. «systemd (Español)». ArchcWiki. 12 de septiembre de 2018. Consultado el 24 de mayo de 2020.
  28. «Resolución General: sistemas de inicio y systemd» (html). Debian. 31 de diciembre de 2019. Consultado el 31 de diciembre de 2019.
  29. McKay, Dave (11 de junio de 2020). «Why Linux’s systemd Is Still Divisive After All These Years» [Por qué el systemd en Linux aún divide a los usuarios después de todos estos años] (html). How-To Geek (en inglés). Archivado desde el original el 11 de junio de 2020. Consultado el 11 de junio de 2020. «“It’s Too Big. It Does Too Much.” Opponents of systemd point out the large, curious mix of functionality it encompasses. All of these features already existed in Linux, and, perhaps, some of them needed a refresh or a new approach. However, to bundle all of this functionality in what is supposed to be an init system is architecturally puzzling. »
  30. Vaughan-Nichols, Steven. «Linus Torvalds and others on Linux's systemd».

Enlaces externos

Fuentes

 Este artículo incorpora texto de un trabajo de contenido libre. Licenciado bajo GNU Free Documentation License 1.3 o posterior Declaración de la licencia: systemd (Español), ArchWiki. Para aprender como añadir texto de licencias libres a artículos de Wikipedia, véase Wikipedia:Agregar textos en licencia libre en Wikipedia. Para más información sobre cómo reutilizar texto de Wikipedia, véanse las condiciones de uso.

Este artículo ha sido escrito por Wikipedia. El texto está disponible bajo la licencia Creative Commons - Atribución - CompartirIgual. Pueden aplicarse cláusulas adicionales a los archivos multimedia.