systemd: qué es, cómo funciona y cómo gestionar servicios en Linux

systemd es el sistema de inicio y gestor de servicios que usa la mayoría de distribuciones Linux modernas: Debian, Ubuntu, Fedora, RHEL y sus derivadas. Tras el arranque, el núcleo ejecuta systemd como primer proceso, con PID 1, y a partir de ahí levanta la red, monta los discos, arranca el servidor web, la base de datos y todo lo demás. En pocas palabras, systemd es el «despachador» que sabe qué servicios deben estar en marcha, en qué orden arrancarlos y qué hacer cuando uno falla.

Para comprobar que tiene systemd basta con ejecutar:

$ ps -p 1 -o comm=
systemd

Por qué surgió systemd

Antes, Linux usaba SysV init: un conjunto de scripts de shell en /etc/init.d/ que se ejecutaban uno tras otro. El esquema era comprensible, pero lento y frágil. Cada script escribía su propio archivo PID, decidía por su cuenta cómo comprobar si un proceso estaba vivo, y reiniciar un servicio caído había que añadirlo por separado.

systemd resuelve estos problemas de forma centralizada:

• Arranque en paralelo. Los servicios se inician a la vez cuando no hay dependencias entre ellos, por eso el arranque es más rápido.
• Dependencias y orden. La descripción del servicio indica explícitamente qué necesita (por ejemplo, la red) y tras qué debe arrancar.
• Supervisión. systemd conoce todos los procesos de un servicio mediante cgroups y puede reiniciarlo tras un fallo.
• Un único registro. journald recoge la salida de todos los servicios, y los registros se consultan con un solo comando.
• Una interfaz única. Cualquier servicio se gestiona igual: systemctl start|stop|restart|status.

Además del gestor de servicios, el proyecto systemd incluye varios componentes: journald (registro), logind (sesiones de usuario), timesyncd (sincronización horaria), resolved (DNS), networkd (red). No todas las distribuciones usan todos, pero systemd como PID 1 y journald están casi en todas partes.

Unidades: de qué está hecho systemd

Todo lo que gestiona systemd se describe mediante unidades (units). Una unidad es un archivo de texto en formato INI; su tipo se deduce de la extensión.

Dónde están los archivos de unidad

Los archivos de unidad se guardan en varios directorios, con un orden de prioridad:

• /usr/lib/systemd/system/ (en Debian y Ubuntu también /lib/systemd/system/) — unidades instaladas por paquetes. No se editan a mano: una actualización del paquete sobrescribiría sus cambios.
• /etc/systemd/system/ — unidades y modificaciones del administrador. Tienen la prioridad más alta.
• /run/systemd/system/ — unidades temporales creadas durante el funcionamiento.

Para ver el contenido efectivo de una unidad con todas sus modificaciones, use systemctl cat nginx.service.

Targets en lugar de niveles de ejecución

Los antiguos runlevels se han sustituido por targets. multi-user.target es el modo servidor habitual, sin gráficos; graphical.target incluye entorno gráfico; rescue.target es el modo de recuperación de un solo usuario. El target predeterminado se consulta con systemctl get-default y se cambia con systemctl set-default multi-user.target.

systemctl: gestionar servicios

systemctl es la herramienta principal para trabajar con systemd. La mayoría de comandos modifican el estado del sistema y requieren sudo.

Cómo leer systemctl status

$ systemctl status nginx
● nginx.service - A high performance web server and a reverse proxy server
     Loaded: loaded (/lib/systemd/system/nginx.service; enabled; preset: enabled)
     Active: active (running) since Mon 2026-10-12 09:14:03 UTC; 2h 5min ago
       Docs: man:nginx(8)
   Main PID: 812 (nginx)
      Tasks: 3 (limit: 2307)
     Memory: 6.1M
        CPU: 154ms
     CGroup: /system.slice/nginx.service
             ├─812 "nginx: master process /usr/sbin/nginx -g daemon on; master_process on;"
             ├─813 "nginx: worker process"
             └─814 "nginx: worker process"

La línea Loaded indica de dónde viene el archivo de unidad y si el arranque automático está activado (enabled). La línea Active muestra el estado actual: active (running), inactive (dead) o failed. El bloque CGroup enumera todos los procesos del servicio: así sabe systemd qué le pertenece.

enable frente a start

Es una confusión frecuente. start arranca el servicio ahora mismo, pero tras un reinicio no vuelve a subir. enable crea un enlace simbólico en el directorio del target (por ejemplo /etc/systemd/system/multi-user.target.wants/): el servicio arranca con el sistema, pero ahora mismo no se está ejecutando. Normalmente se necesitan ambos; use enable --now.

Existe además un tercer estado, mask. systemctl mask servicio enlaza la unidad con /dev/null, y ya no se puede iniciar ni a mano ni como dependencia. Es útil cuando hay que apagar un servicio de forma segura.

journalctl: registros de los servicios

Todo lo que un servicio escribe en stdout y stderr lo captura systemd-journald y lo guarda en un diario binario junto con metadatos: nombre de la unidad, PID, prioridad y hora. El diario se lee con el comando journalctl.

journalctl -u nginx              # registros de un servicio
journalctl -u nginx -f           # seguir en tiempo real, como tail -f
journalctl -u nginx --since "1 hour ago"
journalctl -u nginx -n 50        # últimas 50 líneas
journalctl -b                    # desde el arranque actual
journalctl -b -1                 # el arranque anterior
journalctl -p err -b             # solo errores y de mayor gravedad
journalctl -k                    # mensajes del núcleo
journalctl --disk-usage          # espacio que ocupa el diario

La opción -p filtra por prioridad syslog: emerg, alert, crit, err, warning, notice, info, debug. El nivel elegido incluye todo lo que sea más grave que él.

El diario tras un reinicio

Si el directorio /var/log/journal no existe y en /etc/systemd/journald.conf está Storage=auto, el diario se guarda solo en memoria (/run/log/journal) y desaparece al reiniciar. Para hacerlo permanente, ponga Storage=persistent o cree el directorio y reinicie journald. El tamaño lo limita el parámetro SystemMaxUse=, y los registros antiguos se eliminan con journalctl --vacuum-time=2weeks o --vacuum-size=500M.

journald suele trabajar junto con rsyslog: el diario pasa los mensajes a rsyslog, que escribe los archivos de texto clásicos en /var/log/ y puede enviar los registros a un servidor central.

Arranque automático de un servicio propio: ejemplo de archivo de unidad

Supongamos que tiene una aplicación — un script o un binario — que debe mantenerse en marcha, arrancar con el sistema y reiniciarse si falla. Cree el archivo /etc/systemd/system/myapp.service:

[Unit]
Description=Mi aplicación web
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=myapp
Group=myapp
WorkingDirectory=/opt/myapp
EnvironmentFile=/etc/myapp/env
ExecStart=/opt/myapp/bin/server --port 8080
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Veamos las secciones:

• [Unit] — descripción y dependencias. After= solo fija el orden; Wants= es una dependencia blanda (se arrastra la unidad, pero si no arranca no se detiene el resto). Una dependencia estricta es Requires=.
• [Service] — cómo se ejecuta. Type=simple indica que el proceso de ExecStart es el propio servicio y no pasa a segundo plano. User= lo ejecuta como usuario sin privilegios. Restart=on-failure reinicia el servicio si terminó con error, tras RestartSec segundos.
• [Install] — qué hace enable. WantedBy=multi-user.target significa «arrancar en un inicio normal».

Aplicarlo:

sudo useradd --system --no-create-home --shell /usr/sbin/nologin myapp
sudo systemctl daemon-reload
sudo systemctl enable --now myapp
systemctl status myapp
journalctl -u myapp -f

Errores frecuentes en los archivos de unidad

• Ruta relativa en ExecStart. La ruta al programa debe ser absoluta. systemd no busca comandos en el PATH del usuario como lo haría una shell.
• Olvidar daemon-reload. Tras editar el archivo, systemd sigue usando la versión anterior y lo advierte en status.
• El demonio pasa a segundo plano. Si el programa se bifurca solo pero está indicado Type=simple, systemd considera que el servicio ha terminado. O bien ejecute el programa en primer plano, o use Type=forking con PIDFile=.
• Variables de entorno del perfil. El servicio no ve ~/.bashrc ni /etc/profile. Las variables se definen con Environment= o EnvironmentFile=.

Modificar sin tocar la unidad del paquete

Para cambiar parámetros de un servicio instalado por un paquete sin modificar su archivo, use un drop-in:

sudo systemctl edit nginx

Se abre un editor y los cambios se guardan en /etc/systemd/system/nginx.service.d/override.conf. Allí puede añadir, por ejemplo, una sección [Service] con Restart=always. Al cerrar el editor, systemd vuelve a leer la configuración por sí mismo.

Temporizadores de systemd en lugar de cron

Un timer es una unidad que ejecuta el servicio del mismo nombre según un calendario. Frente a cron tiene ventajas: los registros de la tarea van al journal, admite dependencias y las ejecuciones perdidas pueden recuperarse (Persistent=true). Ejemplo — una copia de seguridad nocturna:

# /etc/systemd/system/backup.service
[Unit]
Description=Copia de seguridad nocturna

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh

# /etc/systemd/system/backup.timer
[Unit]
Description=Ejecutar la copia cada día

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now backup.timer
systemctl list-timers

Una expresión OnCalendar se comprueba con systemd-analyze calendar "*-*-* 03:00:00": el comando muestra cuándo será la siguiente ejecución.

Diagnóstico del tiempo de arranque

systemd guarda la hora de inicio de cada unidad, así que un arranque lento es fácil de analizar:

systemd-analyze                  # tiempo total de arranque
systemd-analyze blame            # unidades ordenadas por tiempo de inicio
systemd-analyze critical-chain   # la cadena que retrasó el arranque
systemd-analyze verify /etc/systemd/system/myapp.service   # comprobar un archivo de unidad

Resumen

systemd es el PID 1 y el gestor de servicios de Linux moderno. Lo describe todo mediante unidades, se controla con systemctl, reúne los registros en un diario que lee journalctl y puede ejecutar tareas con temporizadores en lugar de cron. Para usarlo con seguridad, domine status, enable --now, journalctl -u, y sepa escribir un archivo de unidad sencillo con Restart=on-failure. systemd, journald y el registro de eventos se explican con práctica en nuestro curso de Linux.