Curso de Linux / Consultar servicios de systemd y registros del arranque

En una distribución que utiliza systemd, el gestor del sistema activa servicios y otras unidades después de que se inicien el firmware, el gestor de arranque y el kernel. Para investigar un servicio, compruebe por separado su estado actual y su configuración de activación con systemctl, y lea los registros del mismo arranque con journalctl. Estar habilitado no garantiza estar funcionando.

Este artículo es una introducción a cómo leer el estado, el inicio y la configuración de inicio automático de los servicios en systemd. El procedimiento de recopilar varias evidencias para acotar la causa se trata en Análisis de fallos basado en registros.

El estándar para la práctica de configuración del sistema es Ubuntu 26.04 LTS y VMs de instalación general de la serie Rocky Linux 9. En contenedores, WSL u otras versiones, la configuración de servicios y paquetes puede variar. Preparar primero la recuperación de consola y la verificación de la versión se indica en Crear un entorno de práctica con máquina virtual.

Comprender el flujo de arranque en grandes etapas

El arranque típico de una PC o servidor comienza cuando el firmware inicializa el hardware y busca el gestor de arranque. El gestor de arranque carga el kernel y el entorno inicial necesario, y el kernel prepara los dispositivos, la memoria y la base para la ejecución de procesos. Luego, el primer proceso en el espacio de usuario, el sistema de inicialización, administra los servicios, entre otros. Aquí nos enfocamos en distribuciones donde systemd es PID 1. En entornos que utilizan otros sistemas de inicialización, los comandos y procedimientos pueden diferir.

ps -p 1 -o pid,comm,args
systemctl get-default

Verifique si el PID 1 es systemd en COMMAND o ARGS del primer comando. En contenedores o entornos especiales, puede ser diferente. El segundo comando muestra el target predeterminado. Por ejemplo, multi-user.target es el target de un entorno de texto multusuario habitual, y graphical.target puede ser el target de un entorno gráfico. Un target es un objetivo que agrupa varias unidades y no significa que todos los servicios se inicien secuencialmente en una sola línea.

Unidades de systemd y dependencias

systemd representa los objetos administrados como unidades (unit). .service es un servicio, .target es un target que agrupa varias unidades, .socket está relacionado con activación basada en sockets, y .timer se relaciona con ejecuciones basadas en tiempo. Para usar un servicio, el paquete del programa y la unidad correspondiente deben estar realmente instalados. No intente iniciar o detener servicios del servidor operativo adivinando el nombre.

El orden de inicio de los servicios no sigue un simple orden numérico, sino que se determina según las dependencias y reglas de secuencia entre unidades. Incluso si una unidad está configurada para iniciarse después de otra, eso no crea automáticamente la relación de necesidad. Algunas unidades se ejecutan en paralelo durante el arranque, por lo que al investigar un arranque lento, no se puede determinar la causa solo observando la lista de arriba a abajo.

systemctl list-units --type=service --state=running
systemctl --failed

El primer comando muestra las unidades de servicio que están actualmente cargadas y en ejecución, mientras que el segundo muestra las unidades en estado de fallo. Aunque la lista de fallos esté vacía, no garantiza que la aplicación responda correctamente. Puede ser necesario comprobar por separado el puerto, la respuesta y los registros de la aplicación.

Diferencia entre estado de ejecución y configuración de inicio automático

active describe el estado activo de una unidad; no siempre implica un proceso ejecutándose: un servicio de una sola tarea puede aparecer como active (exited). enabled indica que existen enlaces de activación para esa unidad, pero no garantiza un arranque correcto ni que la aplicación responda. Una unidad static carece de instrucciones de instalación para habilitarla directamente y puede activarse por dependencias u otros mecanismos.

NAME.service en la tabla es un marcador de posición y debe reemplazarse por el nombre de la unidad realmente instalada. Si se detiene una unidad esencial como el servicio SSH utilizado para conectarse al servidor, la conexión remota puede interrumpirse. Ejecute los comandos de cambio solo después de verificar el impacto en el servicio y la ruta de recuperación.

Examinar servicios con comandos de solo lectura

El siguiente systemd-journald.service es una unidad que se puede ver frecuentemente en entornos systemd, pero los resultados pueden ser diferentes en imágenes mínimas o entornos especiales. Todos son comandos de consulta.

systemctl status systemd-journald.service
systemctl is-active systemd-journald.service
systemctl is-enabled systemd-journald.service

status puede mostrar información de carga, estado actual, procesos en ejecución y algunos registros recientes. is-active puede mostrar resultados de active, inactive, failed, etc., y puede devolver un estado de salida distinto de cero cuando está inactivo. is-enabled puede mostrar no solo enabled, sino también disabled, static, entre otros. No considere static como un error de inmediato.

Comandos a tener en cuenta al cambiar servicios

start y stop cambian el estado actual; enable y disable gestionan los enlaces de activación. Por sí solos, los dos últimos no arrancan ni detienen el servicio. restart lo detiene y vuelve a iniciarlo, con posible interrupción. reload solicita recargar la configuración de la aplicación si se admite. enable --now combina la habilitación con el arranque inmediato, que todavía puede fallar.

Después de crear o modificar el propio archivo de unidad, puede ser necesario que daemon-reload haga que el administrador de systemd vuelva a leer la definición. Esto es diferente de reiniciar el proceso de la aplicación restart o volver a leer la configuración de la aplicación reload. Para los cambios en la unidad o configuración de un servicio en funcionamiento, primero realice una copia de seguridad y establezca una ventana de mantenimiento.

Leer los registros del arranque actual con journalctl

El diario de systemd puede reunir registros de varias fuentes, como servicios o el kernel. -b limita el alcance al arranque actual, y -u selecciona solo los mensajes de la unidad especificada. -n 30 solicita los 30 elementos recientes. Si no hay suficientes permisos de consulta, algunos registros pueden no ser visibles; en ese caso, verifíquelo nuevamente con una cuenta de administrador autorizada o con permisos adecuados.

journalctl -b -u systemd-journald.service -n 30 --no-pager
journalctl -b -p warning -n 30 --no-pager
journalctl --list-boots

El primer comando muestra el historial reciente de la unidad en el arranque actual, y el segundo muestra los registros recientes con prioridad de advertencia o superior. Una línea de advertencia no significa que sea la causa del fallo, sino que debe leerse junto con el momento de ocurrencia y el contexto. Si --list-boots no tiene un arranque anterior, puede deberse a la configuración de retención del diario o a la política de espacio de almacenamiento que impide usar registros antiguos. Al investigar arranques anteriores, primero verifique que los registros realmente existan.

Orden de diagnóstico cuando el servicio no se inicia

1. Verifique el nombre exacto de la unidad con problemas y si el paquete está instalado. No manipule otros servicios con nombres similares basándose en conjeturas.
2. Confirme loaded, active y un resumen de las razones del fallo y los registros recientes desde systemctl status.
3. Lea más ampliamente los registros de la misma unidad de arranque desde journalctl -b -u. Busque las causas reales a las que se refieren los mensajes, como errores de configuración, problemas de permisos, conflictos de puertos o fallos de servicios dependientes.
4. Verifique los archivos de configuración y los recursos/relaciones de dependencia necesarios, y haga una copia de seguridad antes de hacer cambios. No libere excesivamente los permisos basándose solo en una línea del registro.
5. Después de corregir la causa, ejecute solo las acciones necesarias en un momento en que el impacto en el servicio sea permisible y confirme is-active y la respuesta real de la aplicación.

Si el tiempo de arranque es un problema, systemd-analyze critical-chain ayuda a examinar rutas de inicio importantes. Sin embargo, no se debe asumir que un servicio en systemd-analyze blame es la causa del retraso total del arranque solo porque su tiempo individual sea largo. Deben interpretarse juntos la ejecución en paralelo y las dependencias.

Documentación oficial

El manual systemctl(1) explica el estado de las unidades y los comandos de cambio, el manual journalctl(1) explica cómo consultar los registros por arranque, unidad y prioridad. En el manual systemd.unit(5) se puede verificar el significado detallado de las unidades y sus dependencias.