Sobre systemd: Mejoras en systemd, Units y Targets; uso de systemctl, compatibilidad con SysV

---

Systemd

Desde hace ya un tiempo son muchas las críticas que surgen entorno al sistema de inicialización systemd, críticas que quiero pensar que son fruto del miedo a lo desconocido, aunque otras opiniones me resultan que están suficientemente documentadas y que quizás tengan razón, o incluso leo cosas que directamente son en mi opinión escritas bajo la ignorancia .

Estar acostumbrados a sistemas de inicio como SysV y sus maravillosos scripts de inicio o incluso a Upstart (ambos con entradas en este mismo blog) no puede ser la escusa para no querer aprender y aceptar las nuevas posibilidades que se nos ofrecen, y que en un futuro próximo veremos si es un sistema factible o no lo es, pero de primera mano creo que deberíamos de confiar una vez mas en GNU/Linux en general ya que prácticamente todas las distribuciones han aceptado o aceptarán en breves, este sistema de inicio como su sistema de inicialización por defecto (aún con compatibilidad con algunos programas que siguen en SysV).

Bien iba a poner enlaces y comentarios curiosos que he encontrado en algunas webs y blogs, pero haría el post demasiado extenso, por lo que he decidido pasar directamente al grano.

Aclaración: Antes de comenzar, decir que no soy ningún experto en la materia, pero he hecho por conocer, por informarme y aprender, para perder el miedo ante lo desconocido pudiendo así, basarme en mi propia experiencia y poder sacar mis propias conclusiones.

Importante: Si eres de los que está buscando el uso concreto del comando sin importar que es y como utilizarlo (o porque ya lo sabes), te aconsejo que te deslices hasta el final del artículo.

¿Que es systemd?

Sistema y administrador de servicios para Linux, compatible con scripts de inicio SysV. Systemd hace uso de la paralelización agresiva, socket y activación D-Bus para iniciar los servicios. Ofrece la puesta en marcha de demonios bajo demanda, realiza el seguimiento de procesos utilizando Linux cgroups, soporta copia instantánea de volumen 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.

Vamos a desglosar un poco esta definición:

• Capacidades de paralelización agresiva usando socket: systemd crea de una misma vez todos los sockets para todos los demonios acelerando así el arranque completo e iniciar más procesos en paralelo. En un segundo paso systemd ejecutará a la vez todos los demonios.
• Activación D-Bus para iniciar servicios: Utilizando la activación D-Bus, un servicio puede ser iniciado la primera vez que es accedido.
• Seguimiento de procesos utilizando Linux cgroups: cgroup también llamados grupos de control, es una característica del kernel para crear límites, políticas e incluso explicar el uso de los recursos de ciertos grupos de procesos. cgroup asocia un conjunto de tareas con un conjunto de parámetros, para uno o más subsistemas, proporcionando un control de servicios y tareas, así como todos sus futuros ‘hijos’ en grupos jerárquico. Un subsistema es un módulo resultado de la agrupación de diversas tareas con el fin de mantener un mejor control sobre estas de forma particular.

Nota: La herramienta systemd-cgls nos muestra recursivamente el contenido del árbol de jerarquías de un determinado grupo de control de Linux.

• Mantiene puntos de montaje y automontaje: Puede utilizarse para montar o desmontar los puntos de montaje, quedando /etc/fstab como una fuente de configuración adicional a la que podremos llamar para su supervisión con la opción «comment=» de fstab para marcar las entradas controladas por systemd.

En definitiva, systemd ha sido creado para ofrecer un inicio mas rápido y flexible que SysV, permitiendo el arranque paralelo de servicios y su inicio basado en la detección de conexión de nueva unidad externa.

Nota: Hasta ahora el PID1 era para el programa init, cosa que ha cambiado en systemd a favor de /usr/lib/systemd/systemd y además systemd al igual que Upstart deja de utilizar el archivo /etc/inittab

Algunas de las mejoras que ofrece systemd:

• Se ha mejorado sustancialmente la velocidad de inicialización del sistema
• systemd asume que cualquier dispositivo puede ser conectado o desconectado en cualquier momento (hotplug)
• systemd utiliza la activación de daemons por medio de sockets, aportando capacidades de paralelización
• Una de sus características es el registro (journal) mediante cgroups de todos los servicios y procesos iniciados
• systemd es modular, esto quiere decir que se han elaborado una seríe de «paquetes» en los que varios servicios son administrados de forma conjunta

¿Que son las Units / Unidades de Servicios?

systemd inicia y supervisa todo el sistema y se basa en la noción de unidades, compuestas de un nombre (el nombre del demonio) y una extensión. Será la extensión la que indique de que tipo de unidad se trata. Además cada unidad tiene su correspondiente archivo de configuración cuyo nombre es idéntico. Un ejemplo sería el servicio httpd.service cuyo archivo de configuración sería httpd.service. Los archivos de unidades disponibles en nuestro sistema podemos encontrarlos en /usr/lib/systemd/system/ y /etc/systemd/system/

Nota: Los archivos bajo el directorio /etc/systemd/system/ prevalecerán en caso de duplicados.

Existen siete tipos diferentes de unidades:

• service: Demonios que pueden ser iniciados, detenidos, reiniciados o recargados.
• socket: Esta unidad encapsula un socket en el sistema de archivos o en Internet. Cada unidad socket tiene una unidad de servicio correspondiente.
• device: Esta unidad encapsula un dispositivo en el árbol de dispositivos de Linux.
• mount: Esta unidad encapsula un punto de montaje en la jerarquía del sistema de archivos.
• automount: Encapsula un punto de montaje automático. Cada unidad automount tiene una unidad mount correspondiente, que se inicia al acceder al directorio de automontaje.
• target: Utilizada para la agrupación lógica de unidades. Referencia a otras unidades, que pueden ser controladas conjuntamente, un ejemplo sería multi-user.target, que básicamente desempeña el papel de nivel de ejecución 3 en el sistema clásico SysV.
• snapshot: Similar a las unidades target.

Entonces los archivos de configuración tendrán los nombres: programa.service, socket.socket, dispositivo.device, puntodemontaje.mount, etc…

Nota: La unidad default.target activa servicios y otras unidades dependientes, durante el arranque de systemd. Esto lo comentaremos en el apartado target

Compatibilidad de systemd con SysV

systemd al igual que Upstart ofrece compatibilidad con SysV (comando service y chkconfig) para aquellos servicios que aun soportan o funcionan únicamente con scripts de inicio SysV (actualmente en 2015, son pocos los servicios ‘comunes‘ que corren bajo SysV). Upstart pese a mantener compatibilidad con los comandos service y chkconfig de SysV implementó su propia utilidad para la administración de servicios, de igual modo systemd lo hace con su herramienta systemctl

#systemctl stop nombreservicio.service

En SysV habilitábamos servicios con chkconfig (o reproducíamos listas de estos para ver cual de ellos se ejecutaba al arranque), algo que ahora bajo systemd podemos hacer con los siguientes comandos:

Habilitar el servicio httpd al arranque del sistema (chkconfig httpd on , para SysV):

#systemctl enabled httpd.service

Listar todas las unidades de servicios instaladas (algo parecido a chkconfig –list)

#systemctl list-unit-files

O solo aquellas que se encuentran en activadas:

#systemctl list-units o #systemctl

Podemos apreciar que a la hora de pasar el nombre del servicio lo hacemos con el nombre completo, es decir incluyendo su sufijo, pero existen una serie de atajos:

• Si no se especifica el sufijo, systemctl asumirá que es .service. Por ejemplo, netcfg y netcfg.service se consideran equivalentes.
• Los puntos de montaje se traducirán automáticamente en la correspondiente unidad .mount. Por ejemplo, si especifica /home será equivalente a home.mount.
• Similar a los puntos de montaje, los dispositivos se traducen automáticamente en la correspondiente unidad .device, por lo tanto, la especificación /dev/sda2 es equivalente a dev-sda2.device.

Nota: Consulte man systemd.unit para más detalles.

Uso de systemctl

La utilidad de administración de las unit de systemd es systemctl, la cual combina las herramientas service y chkconfig de SysV, por lo tanto podremos arrancar, parar, recargar servicios, activar o desactivar servicios en el arranque, listar los estados de los servicios,etc…

Creo que con la siguiente tabla veremos el uso básico de systemctl además de sus «iguales» en SysV.

1* Puede que un servicio este “enable” pero no tiene porqué estar activo cuando iniciemos sesión ya que puede que ese servicio este configurado para ejecutarse solo en determinados runlevels (o target en nuestro caso, veremos que son los target a continuación), a diferencia de chkconfig –list de SysV que mostraba todos los servicios con todos los runlevels posibles y para cada uno indicaba si estaba on o off. Para conseguir algo parecido en systemd, tendríamos que listar los target disponibles y veríamos que servicios se ubican dentro de estos, así sabremos con que target (o runlevel) un servicio será iniciado. Podemos emplear el siguiente listado

#ls /etc/systemd/system/*.wants/httpd.service
/etc/systemd/system/multi-user.target.wants/httpd.service

Este comando nos devuelve que el servicio httpd se encuentra bajo multi-user.target lo que viene siendo el runlevel 3 de SysV. En los siguientes apartados conoceremos los distintos target que de algún modo tienen similitud con los runlevels de SysV

Nota: Podríamos haber omitido el subdirectorio /httpd.service para conocer la lista completa de targets y sus unit (mount, service, socket…)

Podemos hacerlo de una forma inversa (para lo cual hay que conocer el target), es decir ver que servicios están ejecutándose para un target concreto:

#systemctl show -p «Wants» multi-user.target

Además de los comandos de la tabla también podemos ver las units de servicios que tenemos cargados en el sistema con el comando:

#systemctl -t service list-units –all

Con este comando veremos que servicios están cargados y además si están activos o muertos a parte de una pequeña descripción.

Nota: Podemos cambiar service por mount, socket, device… para listar otros tipos (-t) de units.

Si en vez de ver las units cargadas queremos ver cuantas hay instaladas (es decir aquellas que tienen archivos de configuración instalados en nuestro sistema y por lo tanto están disponibles):

#systemctl -t service list-unit-files –all

Nota: Podemos cambiar el tipo de unit o directamente omitir el parámetro -t y listar todas.

Sugerencia: Puede utilizar las siguientes órdenes systemctl con el parámetro -H usario@host para controlar una instancia de systemd en una máquina remota. Esto utilizará SSH para conectarse a la instancia systemd remota.

Target

systemd utiliza target en vez de runlevels (0123456) que reciben un nombre (en vez de un número) para identificar un propósito específico, con la posibilidad de realizar más de una acción al mismo tiempo. Algunos targets pueden heredar todos los servicios de otro target e implementarse con servicios adicionales. La siguiente tabla muestra la similitud entre algunos de los target con los runlevels de SysV:

Nota: Actualmente no existen target similares a los runlevels 2 y 4 de SysV, pero podríamos definirlos nosotros mismos.

Existen otros target que podremos ver con el comando:

#systemctl list-units –type=target

Podemos cambiar de target (o modo de ejecución) actual con el comando:

# systemctl isolate graphical.target

Nota: Esto podría ser equivalente a la orden #telinit 5 de SysV

systemd también nos permite cambiar el target predeterminado e incluso añadir nuevos servicios a otros target, pero antes de esto, es importante dejar claro algunos de los directorios de los que hace uso systemd:

• Los archivos unit (archivos de configuración de service, mount, device…) se encuentran en: /usr/lib/systemd/system/ o /etc/systemd/system/
• Los target (runlevels) igualmente pueden situarse en ambos directorios
• Los directorios *.wants (ubicados igualmente en ambos directorios) contienen los enlaces simbólicos que apuntan a determinados servicios, serán estos servicios los que se ejecuten con el target al que corresponde dicho directorio wants, recordar que si un target precisa de otro, también serán cargados los servicios de este otro target.

Nota: Los archivos unit de /etc/systemd/system tienen una mayor precedencia sobre archivos unidad de /lib/systemd/system

¿Quieres cambiar el target (runlevel) predeterminado de arranque?

El target /etc/systemd/system/default.target es el target predeterminado de arranque, es un enlace simbólico que por defecto apunta a /lib/systemd/system/graphical.target por lo que para cambiar de target de arranque, bastará con eliminar dicho link y crear uno nuevo apuntando al nuevo target.

Si quisiéramos podríamos crear un target desde 0 a nuestro gusto y darle un nombre (mylevel.target) y a continuación habilitarlo:

# systemctl enable mylevel.target

El efecto de esta orden crea un enlace simbólico (/etc/systemd/system/default.target) que apunta a nuestro mylevel.target. Esto solo funciona si hemos añadido la etiqueta [Install] al archivo, de la siguiente manera:

[Install]
Alias=default.target

También podemos añadir o quitar nuevos servicios a un target determinado, bastará con crear nuevos enlaces simbólicos dentro del directorio *.wants del target de arranque (o de algunos de los que dependa) apuntando a los servicios deseados.

Otra forma de modificar el target de inicio es a través de los parámetros que le pasamos al kernel en el archivo de configuración del gestor de arranque añadiendo por ejemplo systemd.unit=multi-user.target para arrancar en nivel3

Journal

journal es un componente mas de systemd, que capta los mensajes syslog, los mensajes de registro del kernel, los del disco RAM inicial y los mensajes de arranque iniciales, así como mensajes escritos en stdout y stderr de todos los servicios, haciendo que estén disponible para el usuario. Se puede utilizar en paralelo, o en lugar de un demonio syslog tradicional, como rsyslog o syslog-ng.

Hasta Fedora 18 (e inclusive a día de hoy, Enero del 2015, en Centos7) el registro de journal se almacena de forma volátil en /run/log/journal por lo que será eliminado tras un reinicio. La intención es que venga configurado por defecto de manera que sea un registro persistente y con directorio principal /var/log/journal (que no venga por defecto no quiere decir que no lo podamos configurar de tal modo).

Una de las razones por las que syslog comenzaba a quedarse «anticuado» es la necesidad por ejemplo de mostrar las últimas líneas del registro de un determinado servicio en el momento de preguntar por su estado (con systemctl), esto necesita que archivos de registro sean descomprimido en tiempo real y a la vez mostrado, algo que con syslog se hacía casi imposible y además, ineficiente y poco seguro.

Hasta ahora nos haremos la idea de que journal es el sustituto de syslog, el cual nos permite filtrar la salida del registro por campos, dejar el registro de forma volátil o volverlo persistente mediante su archivo de configuración (/etc/systemd/journald.conf), darle un tamaño máximo al fichero de registro, permite la compatibilidad con el antiguo syslog mediante el socket /run/systemd/journal/syslog (tendremos que asociar syslog a este socket y no a /dev/log, el paquete syslog-ng proporciona automáticamente la configuración necesaria), reenviar la salida del registro a una terminal, etc…

COMANDO SYSTEMCTL

systemctl: Nos permite controlar el demonio systemd y con ello llevar a cabo una eficaz administración de los servicios.

systemctl [opciones] comando [opciones del comando]

Opciones:

• Indicar el tipo de target: -t (–type=TARGET)
• Filtrar la salida en función del estado: –state=LOAD|SUB|ACTIVE
• Filtrar por las propiedades de unidad/servicio/trabajo: -p (–property=)
• Mostrar todas las unidades/servicios/job cargados: -a (–all)
• Si filtramos por socket, podemos indicar de que tipo de socket se trata: –show-types
• Si vamos a habilitar una unidad, podemos sobreescribir su enlace: -f

Comandos:

• Listar las unidades conocidas (opción por defecto): list-units
• Listar las unidades instaladas: list-unit-files
• Listar sockets: list-sockets
• Iniciar, Detener, Recargar (tipo smb.conf), Reiniciar y Estado de los servicios: start, stop, reload y restar (respectivamente)
• Inicia la unit indicada (y sus dependencias) y detiene el resto. Esto es parecido a cambiar de runlevel: isolate
• Entrar al modo por defecto (parecido a isolate pero sin especificar el target): default
• Entrar en modo de rescate: rescue
• Entrar en modo de emergencia: emergency
• Cerrar la sesión y apagar el sistema: halt
• Apagar el sistema (como si quitamos el cable de corriente): poweroff
• Reiniciar el sistema: reboot
• Entrar en modo suspensión: suspend
• Hibernar el equipo: hibernate
• Comprobar si una unit se encuentra en ejecución: is-active
• Comprobar si una unit está en estado «failed»: is-failed
• Mostrar las propiedades de una unit: show
• Mostrar las dependencias de una unit (si no especificamos una en concreto se toma default.target): list-dependencies
• Habilitar / Deshabilitar una unit: enable , disable
• Comprobar si una unidad está habilitada: is-enabled
• Resetear una unit: preset
• Mostrar el runlevel (target) que tenemos por defecto para iniciar el sistema: get-default
• Setear el target con el que queremos arrancar el sistema: set-default
• Listar los trabajos (Jobs) que están activos: list-jobs
• Cancelar un trabajo: cancel
• Recargar el archivo de una unidad (httpd.service): daemon-reload

shutdown, poweroff, halt, reboot: Estos comandos son equivalentes a init 0 e init 6. La mejor forma de apagar el sistema es con shutdown. Además este permite una gran variedad de opciones.

shutdown [opcion] argumento [mensaje]

Opciones:

• Detener el sistema: -H
• Apagar el sistema: -P
• Apagar el sistema (equivalente a -P a menos que -H haya sido especificada): -h
• Reiniciar el sistema: -r
• Cancelar una tarea de shutdown pendiente: -c
• No enviar mensajes después de ejecutar la orden shutdown: –no-wall

Ejemplos:

• Apagar el sistema a las 01:30 AM y además envía un mensaje

# shutdown -h 1:30 “A las 1:30 de la madrugada el sistema va a ser apagado”

• Cancelamos la acción anterior, pues nos hemos equivocado de hora:

# shutdown -c “Perdonar el sistema no va a ser apagado, quizás a las 13:30, pero avisaremos. Disculpen”

NOTAS:

Podremos descargar systemd desde la siguiente página oficial: http://www.freedesktop.org/software/systemd/ o bien consultar su documentación oficial http://freedesktop.org/wiki/Software/systemd/

Puedes ampliar la información aquí dada, e incluso conocer otras funcionalidades o aspectos de systemd como:

• Características de systemd (ampliadas)
• Línea de comandos de arranque del Kernel
• Cambiar el número de gettys por defecto
• Personalizar un archivo unidad o agregar uno personalizado
• Inicio de sesión automático en una terminal
• Implementación readahead (lectura anticipada)
• Escribir archivos .service personalizados
• Archivos temporales y temporizadores

a través de algunos sitios:

https://fedoraproject.org/wiki/Systemd/es
https://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet/es
https://wiki.archlinux.org/index.php/Systemd_%28Espa%C3%B1ol%29
https://wiki.ubuntu.com/SystemdForUpstartUsers
https://wiki.archlinux.org/index.php/Systemd