Introducción a los conceptos básicos de systemd

La primera sección que se encuentra en la mayoría de los archivos de unidad es [Unit]. Esta sección se utiliza para definir los metadatos del archivo de unidad y configurar la relación del archivo de unidad con otros archivos de unidad. Esta sección se suele colocar en la parte superior porque proporciona una descripción general del archivo de unidad.

Estas secciones contienen directivas específicas para su tipo respectivo. Consulte la Sección 4, “Tipos de archivos de unidad” para obtener una lista de los tipos disponibles. Tenga en cuenta que los tipos device, target, snapshot y scope no tienen una sección específica de tipo.

Suele ser la última sección del archivo de unidad y es opcional. Se utiliza para definir el comportamiento de un archivo de unidad cuando está habilitado o inhabilitado. Cuando se habilita un archivo de unidad, se inicia automáticamente al arrancar. Según la unidad específica, podría haber una dependencia en otras unidades relacionadas necesaria para funcionar correctamente. Por ejemplo, chrony requiere las directivas After, Wants y Before, que son todas las dependencias con las que tiene que trabajar chrony.

Describe cómo gestionar un servicio o una aplicación. Esto incluye cómo iniciar o detener el servicio, volver a cargar su archivo de configuración (si procede), en qué condiciones se inicia el servicio automáticamente y la información de dependencia o jerarquía de los archivos de unidad relacionados.

Este archivo de unidad lo crea automáticamente systemd a partir de la información recibida de la interfaz D-Bus y se utiliza para gestionar conjuntos de procesos del sistema que se crean externamente.

Define una vía para la activación basada en vías. Por defecto, se activa un archivo de unidad .service con el mismo nombre base. inotify es una API del kernel que utilizan los programas que desean recibir notificaciones sobre cambios en los archivos.

El comando systemctl snapshot crea automáticamente un archivo de unidad .snapshot. Este comando crea instantáneas temporales del estado actual del sistema. Puede modificar el estado actual del sistema después de realizar cambios. Las instantáneas se utilizan para deshacer estados temporales.

Define un temporizador gestionado por systemd. Esto es similar a una trabajo cron para la activación programada o retrasada. Un archivo de unidad con el mismo nombre, pero con la extensión de archivo .service se inicia cuando se alcanza el temporizador.

Asocia nodos de grupo de control de Linux, que permiten asignar o restringir recursos a cualquier proceso asociado con el segmento. El nombre indica la jerarquía dentro del árbol del grupo de control. Las unidades se colocan en sectores por defecto en función de su tipo.

Proporciona sincronización para otras unidades durante el arranque o un cambio de estado, o lleva el sistema a un nuevo estado. Otras unidades especifican su relación con los destinos para sincronizarse con las operaciones del destino.

Describe una red, un zócalo IPC o un búfer FIFO que systemd utiliza para la activación basada en zócalos. Hay un archivo .service asociado que se inicia cuando se ve una actividad en el zócalo que define esta unidad.

Define un dispositivo que ha sido designado para la gestión de systemd por udev o un sistema de archivos sysfs. No todos los dispositivos tienen el archivo .device. Este archivo de unidad es necesario para realizar pedidos, montar un dispositivo o acceder a uno.

Define el espacio de intercambio en el sistema. El nombre del archivo de unidad debe reflejar el dispositivo o la vía de archivo del espacio.

Define un punto de montaje en el sistema que debe gestionar systemd. Este archivo recibe el nombre de la vía de montaje y las barras inclinadas se convierten en guiones. Las entradas incluidas en /etc/fstab pueden tener unidades creadas automáticamente.

Define un punto de montaje que se monta automáticamente. Nombra el archivo según el punto de montaje al que hace referencia. Se requiere un archivo de unidad .mount que coincida para definir los detalles del montaje.

Por ejemplo, si la unidad A tiene Wants=unit B, cuando se ejecuta la unidad A, también se ejecuta la unidad B. Pero da igual si la unidad B se inicia correctamente o no para que la unidad A se ejecute correctamente.

Si la unidad A tiene Requires=unit B, ambas unidades se ejecutan, pero si la unidad B no lo hace correctamente, la unidad A se desactiva. No importa si los procesos de la unidad A se estaban ejecutando correctamente.

Por ejemplo, si la unidad A tiene Before=unit B, cuando se ejecutan ambas unidades, la unidad A se ejecuta completamente antes que la unidad B.

Si la unidad A tiene After=unit B, cuando ambas unidades se ejecutan, la unidad B se ejecuta completamente antes que la unidad A.

Arranca por defecto. El archivo default.target es un enlace simbólico al archivo de destino real, por ejemplo graphical.target para una estación de trabajo de escritorio. Para un servidor, normalmente es graphical.target.

Apaga y desactiva el sistema.

La unidad de destino que extrae el sistema base e inicia una sesión de shell de rescate.

Configura un sistema multiusuario no gráfico (consola).

Utiliza un sistema gráfico multiusuario con servicios de red.

Apaga y rearranca el sistema.

Antes de iniciar o habilitar un servicio systemd, compruebe la sintaxis del archivo de unidad para asegurarse de que no hay errores. Por ejemplo:

> sudo systemd-analyze verify /etc/systemd/system/my-custom-service.service

El comando analiza el archivo de unidad e informa de los errores de sintaxis, los archivos que faltan u otros problemas. Debe solucionar los problemas notificados antes de habilitar e iniciar el servicio.

Si experimenta algún problema con un servicio systemd, consulte el registro del servicio. Por ejemplo:

> sudo  journalctl -u my-custom-service.service

El comando muestra los registros del servicio especificado, incluidos los mensajes de error, las advertencias u otra información relevante. Puede utilizar estos registros para identificar y solucionar problemas con el servicio.

Si un servicio está causando problemas durante el proceso de arranque, puede utilizar systemd-analyze plot command para visualizar el proceso de arranque e identificar problemas. Por ejemplo:

> sudo systemd-analyze plot > boot-plot.svg

El comando crea un archivo SVG denominado boot-plot.svg que contiene una representación gráfica del proceso de arranque y los posibles problemas. Esto incluye la hora de inicio y finalización de cada servicio. Puede abrir este archivo en un visor de imágenes compatible con SVG o en un navegador Web para analizar los servicios que están causando problemas durante el proceso de arranque.

Para averiguar qué servicios han fallado e inspeccionar la salida del registro:

> sudo systemctl --state=failed

Para averiguar el estado de tiempo de ejecución actual de un servicio:

> sudo systemctl status SERVICE

Si el apagado o el rearranque tardan mucho tiempo, puede deberse a un servicio que no se está cerrando. systemd espera algún tiempo a que se cierre cada servicio antes de intentar terminarlo. Un problema común es que haya un servicio suspendido o un proceso de apagado que se haya quedado atascado. Para averiguar si es el caso, utilice lo siguiente:

> sudo systemctl poweroff
  Failed to power off system via logind: There's already a shutdown or sleep operation in progress

> sudo systemctl list-jobs

Puede cancelar los trabajos en ejecución y en espera y volver a apagar o rearrancar:

> sudo systemctl cancel

> sudo systemctl stop systemd-suspend.service

Para averiguar el estado de tiempo de ejecución actual de un servicio:

> sudo systemctl status SERVICE

Utilice una vía absoluta para los archivos ejecutables y los archivos necesarios, como los archivos de configuración o los guiones del archivo de unidad systemd. systemd no se basa en las variables de entorno del usuario como $PATH para localizar archivos.

Utilice la directiva ExecReload de la sección [SERVICE] cuando desee definir un comando específico que deba ejecutarse cuando cargue de nuevo un servicio con el comando systemctl reload. Esto es útil para los servicios que pueden volver a cargar dinámicamente su configuración sin reiniciar.

[Service]
ExecStart=PATH_TO_EXECUTABLE
ExecReload=PATH_TO_RELOAD_SCRIPT

Utilice la directiva RestartSec de la sección [SERVICE] cuando desee definir un retraso (en segundos) antes de que se reinicie el servicio después de un fallo. Esto es útil para los servicios que requieren un tiempo especificado para liberar recursos o evitar bucles de reinicio rápido que pueden provocar una carga alta del sistema.

[Service]
ExecStart=PATH_TO_EXECUTABLE
Restart=on-failure
RestartSec=5

Puede inhabilitar el modo de emergencia en un equipo remoto, por ejemplo, un equipo virtual alojado en Google Cloud. Si este modo está habilitado, el equipo no podrá conectarse a la red. Por ejemplo:

> sudo systemctl mask emergency.service

> sudo systemctl mask emergency.target