Hablemos de SystemD (Parte 2)
SystemD es un sistema y administrador de servicios para Linux, el cual es compatible con scripts de inicio (init) SysV y con Linux Standard Base (LSB).
SystemD proporciona capacidades de paralelización agresivas, utiliza socket y activación D-Bus para iniciar los servicios.
En computación, D-Bus o DBus es un mecanismo de comunicación entre procesos (IPC) y llamadas a procedimiento remoto (RPC), el cual permite la comunicación entre múltiples programas de computadora, que se ejecutan al mismo tiempo en la misma máquina.
SystemD ofrece la puesta en marcha de demonios bajo demanda, realiza el seguimiento y rastreo de procesos utilizando Linux cgroups, el cual es una característica del núcleo de Linux que limita, representa, y aísla los recursos usados (CPU, memoria, disco E / S, la red, etc.) de una colección de procesos.
SystemD soporta copia instantánea y restauración de volúmenes (snapshot) y la restauración de estado del sistema, mantiene puntos de montaje y automontaje e implementa un elaborado servicio lógico de control transaccional basado en la dependencia.
Systemd posee además otras características como proporcionar el inicio por demanda a los daemons e implementar la lógica de control basada en dependencias transaccionales.
Ampliando lo resumido hasta ahora, Systemd inicia y supervisa todo el sistema y se basa en la noción de unidades compuestas de un nombre, tipo y coincidencia de un archivo de configuración con el mismo nombre y tipo (por ejemplo, una unidad avahi.service tiene un archivo de configuración con el mismo nombre y es una unidad de encapsulado del demonio Avahi).
En el sistema existen siete tipos diferentes de unidades:
service: este es el tipo más obvio de unidad: demonios que pueden ser iniciados, detenidos, reiniciados, recargados.
socket: Esta unidad encapsula un socket en el sistema de archivos o en Internet. Actualmente systemd soporta el funcionamiento de los tipos de sockets AF_INET, AF_INET6, AF_UNIX, datagram y paquetes secuenciales. También puede soportar FIFOs clásicos como transporte. Cada unidad socket tiene una unidad de servicio correspondiente, que se inicia si la primera conexión entra en el socket o FIFO (por ejemplo, nscd.socket inicia nscd.service en una conexión entrante).
device: esta unidad encapsula un dispositivo en el árbol de dispositivos de Linux. Si un dispositivo está marcado para ello a través de reglas udev, se expondrá como una unidad device en systemd. Las propiedades establecidas con udev pueden utilizarse como configuración fuente para establecer dependencias para unidades device.
mount: esta unidad encapsula un punto de montaje en la jerarquía del sistema de archivos.
automount: este tipo de unidad encapsula un punto de montaje automático en la jerarquía del sistema de archivos. Cada unidad automount tiene una unidad mount correspondiente, que se inicia (es decir, montada) tan pronto como se accede al directorio de automontaje.
target: este tipo de unidad se utiliza para la agrupación lógica de unidades: en vez de realmente hacer nada por sí misma simplemente hace referencia a otras unidades, que así pueden ser controladas conjuntamente, (por ejemplo, multi-user.target, que es un objetivo que básicamente desempeña el papel de nivel de ejecución 5 en el sistema clásico SysV; o bluetooth.target que es solicitado tan pronto como esté disponible un adaptador bluetooth y que simplemente recibe servicios relacionados con bluetooth que de lo contrario no tendrían que iniciarse: bluetoothd, obexd y cosas por el estilo).
snapshot: similar a las unidades target, snapshots en realidad no hacen nada ellas mismas y su único propósito es hacer referencia a otras unidades.
SystemD, es por mucho la mejor propuesta de reemplazo para sysvinit. Su primera liberación se realizó el 30 Marzo 2010 y fue originalmente creado por Lennart Poettering de Red Hat.
Decir también que se ha cuestionado sobre SystemD, diciendo por ejemplo; que “representa un incremento monumental en la complejidad, una abominable y violenta bofetada en la cara a la filosofía Linux, y su inherente naturaleza dominante y viral lo convierte en una especie de segundo kernel, desparramándose por todo el ecosistema Linux”.
Sobre su adopción por parte de las diferentes distribuciones de Linux, se tiene que en mayo de 2011, Fedora 15 se convirtió en la primera distribución principal de Linux en habilitar SystemD por defecto. No obstante, la propagación continua, pues otras distribuciones han adoptado SystemD de forma predeterminada.
Tal es el caso de Debian GNU/Linux desde la versión 8 “Jessie”, Frugalware 1.5 y superiores Mageia desde la versión 2,18, Mandriva 2011, openSUSE 12.1 y superiores, Arch Linux desde octubre de 2012, Siduction desde diciembre de 2013, CentOS 7 desde julio de 2014 y Ubuntu a partir de su versión 15.04 (esperada para abril de 2015).
Gentoo es otra distribución en la que systemd está disponible, pero como paquetes no soportados oficialmente.
Asi las cosas, SystemD es sin duda el gran ganador -a pesar de-, como el sustituto de SysVinit en el manejo de las tareas y servicios del sistema Linux.