Configuración y control de unidades en systemd

Systemd es el sistema de configuración y control de servicios adoptado por la mayoría de distribuciones de linux actuales. Nacido para sustituir a init, su camino no ha estado exento de polémica. Sus detractores le achacan principalmente su tamaño y complejidad, siendo para algunos contrario a los principios de simplicidad y sencillez donde un elemento tiene que hacer solo una cosa, debe interactuar de forma sencilla con otros elementos y ser también fácilmente sustituido.

De cualquier forma es actualmente un elemento base de todas las distribuciones y su conocimiento es esencial para cualquiera dedicado a la administración de sistemas GNU/Linux. Es un sistema que aporta mejoras en la paralelización de servicios, mejora el arranque del sistema y permite un mejor control de los servicios y sus dependencias.

Systemd no es un único servicio o demonio, sino una colección de servicios, librerías, tecnologías y complementos del kernel.

Imágen: Shmuel Csaba Otto Traian - Licencia Creative Commons Genérica

Archivos de Unidades

La configuración de systemd, adopta un enfoque muy diferente al de init donde se organizaban los scripts de inicio en diferentes directorios por niveles de ejecución. En systemd la configuración reside en unos archivos, llamados archivos de unidades, que se encuentran en la carpeta /lib/systemd/system, en los que se describen las unidades, cuando deben ejecutarse y en que orden. Estos archivos se consideran archivos de sistema y no deben modificarse. Si queremos realizar alguna modificación podemos copiarlo a la carpeta /etc/systemd/system (o crear uno en esta carpeta) y realizar las modificaciones que necesitemos.

Dentro de /etc/systemd/system y sus subcarpetas encontramos muchos enlaces simbólicos a archivos de unidad. Cuando se deshabilitan unidades el sistema elimina el enlace simbólico de /etc/systemd/system que apuntan a /lib/systemd/system. Por ejemplo, si tenemos el servicio vsftpd instalado y lo deshabilitamos, el sistema elimina el enlace de la carpeta /etc/systemd/system/multi-user.target.wants, pero mantiene el fichero vsftpd.service en la carpeta /lib/systemd/system.

Las unidades pueden ser,  un servicio (service.service), un socket ( socket.socket), un dispositivo (device.device), un punto de montaje (mount.mount), un punto de automontaje (automount.automount), una partición o fichero swap (swap.swap), un objetivo de inicio (target.target), una ruta que se puede usar para la activación basada en rutas (path.path), un temporizador (timer.timer), un slice asociado con los nodos del Grupo de Control de Linux (slice.slice) o una unidad scope creada automáticamente a partir de la información recibida de sus interfaces de bus (scope.scope).

Sintaxis de los Archivos de Unidades

La sintaxis de los ficheros de unidades es sencilla, organizada en diferentes secciones que encabezan un bloque designado por una palabra entre corchetes [Unit]. Los diferentes bloques se componen de diferentes opciones con formato parámetro=valor. La siguiente es la unidad correspondiente a ssh.service:

[Unit]
Description=OpenBSD Secure Shell server
Documentation=man:sshd(8) man:sshd_config(5)
After=network.target auditd.service
ConditionPathExists=!/etc/ssh/sshd_not_to_be_run

[Service]
EnvironmentFile=-/etc/default/ssh
ExecStartPre=/usr/sbin/sshd -t
ExecStart=/usr/sbin/sshd -D $SSHD_OPTS
ExecReload=/usr/sbin/sshd -t
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartPreventExitStatus=255
Type=notify
RuntimeDirectory=sshd
RuntimeDirectoryMode=0755

[Install]
WantedBy=multi-user.target
Alias=sshd.service 

Algunas de las opciones de los archivos de unidades, comunes a todas las unidades son:

Opción Descripción
[Unit]  
Description Descripción de la unidad
Documentation URIs referente a la documentación
Requires Unidades que requiere el servicio. Este es un requerimiento estricto, por tanto si la unidad requerida falla lo hará también esta
PartOf Unidades dependientes, paradas y arrancadas por el servicio. No es un requerimiento estricto, de tal manera que aunque la unidad dependiente falle el servicio arrancará
Wants Unidades solicitadas por el servicio. No es un requerimiento estricto, de tal manera que aunque la unidad dependiente falle el servicio arrancará
Conflicts Dependencias negativas de la unidad. Arrancar esta unidad finalizará las unidades listadas en esta opción
Before Orden de unidades. La unidad comenzará antes de las unidades listadas
After Orden de unidades. La unidad esperará hasta que las unidades listadas comiencen
OnFailure Unidades que se ejecutarán en caso de que la unidad falle
SourcePath  Fichero desde donde la configuración se va a generar
[Install]  
WantedBy Configura el enlace simbólico en el subdirectorio .wants de la unidad listada. Cuando la unidad listada se activa, lo hace también esta unidad. No es un requerimiento estricto
RequieredBy Configura el enlace simbólico en el subdirectorio .requires de la unidad listada. Cuando la unidad listada se activa, lo hace también esta unidad. Este es un requerimiento estricto
Alias Nombre adicional de la unidad
Also Unidades adicionales a instalar con esta unidad

Los archivos de unidad de tipo service, socktets, mount y swap comparten las mismas opciones para el entorno de ejecución de la unidad. Van dentro de los bloques tipo [Service], [Socket], etc. y son las siguientes:

Opción Descripción
WorkingDirectory Estable el directorio de trabajo para la aplicación
RootDirectory Directorio Root para la aplicación
User, Group Id's de usuario y grupo
Nice Selecciona prioridad para la aplicación
CPUscledulingPriority Programación de prioridad en CPU para la aplicación
UMask Mascara para la creación de ficheros, 022 por defecto
Enviroment Variables de entorno para la aplicación
StandardOutput Redirigir la salida estándar (consola, log, null)
SysLogLevel Nivel para loggin: info, warn, alert, debug
DeviceAllow, DeviceDeny Controla el acceso de la aplicación a dispositivos
ControlGroup Asigna la aplicación a un grupo de control

Las unidades service corresponden a los demonios o servicios que corren en la máquina tipo servidor web o ssd, o servicios locales como avahi, upower, etc. Las opciones de unidad más importantes para service son:

Opción Descripción
ExecStart Comando que se ejecutará para iniciar el servicio
ExecStop, ExecReload Comando a ejecutar para parar o recargar el
Type Tipo de servicio, por defecto simple (simple, forking, dbus, notity, idle)
ExecStartPre, ExecStartPost Comando que se ejecutará antes y después del comando en ExecStart
TimeStartSec Tiempo a esperar antes de la ejecución del comando
Restart Restaurar cuando ExecStart finalice
PermissionsStartOnly True / False (verdadero/falso). Si true, los permisos base se aplican solo a ExecStart 
RootDirectoryStartOnly True / False (verdadero/falso). Si true, la opción RootDirectory se aplica solo a ExecStart

La activación de unidades bajo demanda mejora notablemente el tiempo de arranque de un sistema y facilita el control y mantenimiento de los servicios. Los archivos de configuración de unidades ".socket" corresponden a un IPC, un socket de red, o un sistema de archivo FIFO controlado y supervisado por systemd para la activación basada en socket. Para cada archivo de socket, debe existir un archivo de servicio coincidente, que describa el servicio para iniciar el tráfico entrante en el socket (veremos un ejemplo en entradas posteriores). Las opciones más importantes de las unidades socket son:

Opción Descripción
ListenStream Dirección de escucha para el stream. Puede ser un número de puerto, la ruta del nombre de socket, o una dirección IP4 o IP6 con el numero de puerto
Accept En caso de true, una instancia del servicio se lanza por cada conexión. Si es false, una instancia gestiona todas las conexiones
MaxConnections Número máximo de conexiones para un servicio
Service Unidad de tipo service que activa el socket. Por defecto es una unidad service con el mismo nombre que la unidad socket

Systemd utiliza las unidades path para monitorizar rutas. Las opciones de unidad más importantes para path son:

Opción Descripción
PathExists Se activa si el fichero existe
PathExistsGlob Se activa si existe un fichero que coincida con un patrón
PathModified Se activa si se modifica el fichero

Existen más opciones dependientes del tipo de unidad. Veremos algunas en posteriores entradas, pero podemos ver una descripción general en la página de man systemd.unit.

Manejo de Unidades

Para manejar todo esto, aunque es posible todavía utilizar los antiguos comandos de gestión de servicios como service, systemd incluye sus propias herramientas nativas para estas tareas, la principal es sin duda systemctl.

Si ejecutamos el comando systemctl sin ningún argumento invoca el default-list y nos muestra todos los servicios, sockets, targets, puntos de montaje y dispositivos cargados y activos. Si queremos filtrar el resultado, por ejemplo mostrando solo los servicios, usamos --type=service:

david@sglan-pc7:~$ sudo systemctl list-units --type=service
UNIT                                                    LOAD   ACTIVE SUB     DESCRIPTION                         
accounts-daemon.service                                 loaded active running Accounts Service                    
acpid.service                                           loaded active running ACPI event daemon                   
alsa-restore.service                                    loaded active exited  Save/Restore Sound Card State       
apparmor.service                                        loaded active exited  AppArmor initialization             
apport.service                                          loaded active exited  LSB: automatic crash report generatio
atd.service                                             loaded active running Deferred execution scheduler        
avahi-daemon.service                                    loaded active running Avahi mDNS/DNS-SD Stack             
binfmt-support.service                                  loaded active exited  Enable support for additional executa
blk-availability.service                                loaded active exited  Availability of block devices       
bolt.service                                            loaded active running Thunderbolt system service   
...
wpa_supplicant.service                                  loaded active running WPA supplicant                      

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

77 loaded units listed. Pass --all to see loaded but inactive units, too. 

Para mostrar también las unidades que no están activas usamos el parametro list-unit-files:

david@sglan-pc7:~$ sudo systemctl list-unit-files --type=service 
UNIT FILE                                  STATE          
accounts-daemon.service                    enabled        
acpid.service                              disabled       
alsa-restore.service                       static         
alsa-state.service                         static         
alsa-utils.service                         masked         
anacron.service                            enabled        
apparmor.service                           enabled        
apport-autoreport.service                  static         
apport-forward@.service                    static         
apport.service                             generated      
apt-daily-upgrade.service                  static         
apt-daily.service                          static         
atd.service                                enabled 
...
wacom-inputattach@.service                 static         
whoopsie.service                           disabled       
wpa_supplicant-wired@.service              disabled       
wpa_supplicant.service                     enabled        
wpa_supplicant@.service                    disabled       
x11-common.service                         masked         

258 unit files listed.
       

Los estados más frecuentes en que podemos encontrar las unidades son:

Estado Significado
bad Algún tipo de problema con systemd, generalmente un fichero de unidad incorrecto
disable Unidad presente pero no configurada para comenzar de forma autónoma en el arranque
enabled Instalada y ejecutable; comenzará de forma autónoma
indirect Se encuentra deshabilitada, pero existen unidades que pueden habilitarla de forma indirecta
linked Unidad de fichero disponible a través de un symlink
masked Esta unidad a sido escluida de systemd y no puede ser activada
static La unidad no está habilitada y no tiene disposiciones para habilitarse en la sección "[Instalar]"
generated Unidades generadas dinámicamente que son habilitadas implícitamente por su generador

En una próxima entrada veremos con más detalle las opciones de systemctl.

Modificado por última vez enMartes, 28 Julio 2020 20:47
(0 votos)
Etiquetado como :

Deja un comentario

Asegúrese de introducir toda la información requerida, indicada por un asterisco (*). No se permite código HTML.