En nuestros últimos tres posts («Niveles de corrida o runlevels en Linux«, «Administración de servicios en SystemV«, y «Habilitar y deshabilitar servicios con chkconfig«) explicamos el concepto de runlevels y el uso de chkconfig para decidir en qué niveles de corrida debería estar activo por defecto un servicio dado. También mencionamos que es mediante el proceso init que se inician todos los demás bajo el esquema de SystemV. En este post comenzaremos a explicar cómo realizar la administración de servicios con systemd, el sistema de inicio y administración de servicios que -a partir de hace un par de años- terminó desplazando a init de las distribuciones Linux más importantes.
Servicios con systemd
Es importante aclarar que systemd no surgió como un reemplazo de init porque este último fuera defectuoso (o broken en la jerga Linuxera) o porque hubiera usuarios y administradores que estuvieran descontentos con el mismo. Más bien, comenzó como un proyecto para desarrollar un sistema que fuera más eficiente al 1) levantar menos servicios durante el inicio (solamente aquellos que fueran estrictamente necesarios de acuerdo al uso esperado y al hardware disponible), y 2) hacerlo en paralelo, en vez de manera secuencial. En otras palabras, se comenzó a buscar un sistema de inicio y de administración de servicios que pudiera reaccionar dinámicamente ante cambios en el software y en el hardware. Si lo pensamos bien, esta es una característica distintita de los sistemas de cómputo actuales. Por ejemplo, no hay necesidad de mantener el servicio de impresión CUPS corriendo si no hay ninguna impresora conectada al equipo o disponible a través de la red. Por otra parte, queremos que se inicie de manera transparente si esa condición cambia.
A pesar de las bondades mencionadas en el párrafo anterior, muchas personas se opusieron tenazmente a la adopción de systemd por parte de su distribuciones favoritas. Sin embargo, las reservas de la comunidad eventualmente cedieron o no fueron tenidas en cuenta, resultando en la adopción de systemd en Fedora -lo cual derivó en Red Hat Enterprise Linux 7 y eventualmente en CentOS 7-, ArchLinux, Debian, Ubuntu, y derivados de estos últimos.
En este link pueden leer una historia más detallada del desarrollo y las características estructurales de la administración de servicios con systemd. En el próximo post explicaremos cómo utilizarlo como reemplazo de init. ¡Nos leemos en breve!