Servicios con systemd

Qué es un servicio

Un servicio -o demonio- es un programa que corre de fondo, sin ventana y sin que nadie lo lance a mano: el servidor web, la base de datos, el propio SSH por el que entraste.

Quien los arranca, los vigila y los vuelve a levantar si se caen es systemd, el gestor de servicios de Ubuntu. Administrar un servidor es, en buena medida, hablar con él.

Los cuatro comandos que se usan a diario

sudo systemctl status nginx      # como esta (el que mas se usa)
sudo systemctl restart nginx     # pararlo y volverlo a arrancar
sudo systemctl stop nginx        # pararlo ahora
sudo systemctl start nginx       # arrancarlo ahora

# Y los dos que deciden que pasa tras un reinicio del servidor
sudo systemctl enable nginx      # que arranque solo al encender
sudo systemctl disable nginx     # que NO arranque solo

start no es enable, y confundirlos se paga de madrugada. start lo arranca ahora; enable lo apunta para que arranque en cada encendido.

Un servicio arrancado solo con start funciona perfectamente durante semanas… hasta el primer reinicio, y entonces no vuelve. Es de los fallos que peor se diagnostican, porque «no se tocó nada».

Leer el estado de un servicio

systemctl status es el comando más útil del curso. En una pantalla dice si está vivo, si arranca solo, desde cuándo corre y las últimas líneas de su registro.

Un servicio sano

sudo systemctl status nginx

Resultado

● nginx.service - A high performance web server
     Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; preset: enabled)
     Active: active (running) since Sun 2026-06-15 03:12:04 -05; 2 months 22 days ago
   Main PID: 1287 (nginx)
      Tasks: 5 (limit: 9448)
     Memory: 12.4M
        CPU: 4min 51.203s

Las dos líneas que hay que mirar

Loaded: … enabled

Dice si arrancará solo tras un reinicio del servidor.

enabled sí; disabled no. Es la línea que delata el error de start sin enable.

Active: active (running)

Está vivo ahora mismo, y desde cuándo.

Ese «desde cuándo» vale oro: si dice cuatro minutos y nadie lo tocó, se reinició solo, y ahí está el problema real.

active (exited)

Parece un error y no lo es. Hay unidades que hacen una tarea y terminan -montar un disco, aplicar una regla de red-.

Hicieron su trabajo y salieron bien. Lo que sí es un fallo es failed.

Cuando uno no arranca: el procedimiento

La tentación es reiniciar otra vez, y otra. Reiniciar a ciegas no arregla casi nunca y borra pistas. El orden correcto son cuatro pasos, y funciona con cualquier servicio aunque no sepas nada de él.

Los cuatro pasos, en este orden

1. Leer el estado completo
sudo systemctl status nginx -l --no-pager

Las últimas líneas del registro salen ahí mismo, y en más de la mitad de los casos el motivo está escrito con todas las letras.
2. Leer el registro del servicio
sudo journalctl -u nginx -n 50 --no-pager

-u filtra por unidad y -n 50 trae las últimas 50 líneas. Se busca la primera línea de error, no la última: las siguientes suelen ser consecuencia.
3. Comprobar la configuración antes de reintentar
Muchos servicios saben revisarse solos: sudo nginx -t valida la configuración del servidor web y dice el archivo y la línea del error.

Es el paso que más tiempo ahorra y el que más se salta.
4. Ahora sí, reiniciar y verificar
sudo systemctl restart nginx y otra vez status.

Terminar sin verificar es como no haberlo hecho: el comando puede volver sin error y el servicio caerse tres segundos después.

Un fallo real, y lo que dice el registro

sudo systemctl status nginx

Resultado

● nginx.service - A high performance web server
     Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled)
     Active: failed (Result: exit-code) since Mon 2026-09-07 09:52:11 -05; 8s ago
    Process: 4471 ExecStartPre=/usr/sbin/nginx -t (code=exited, status=1/FAILURE)

nginx[4471]: nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)

Ahí está todo: «Address already in use». El puerto 80 lo tiene otro programa. No es un problema de nginx, y reiniciarlo cien veces no lo va a arreglar. Se averigua quién ocupa el puerto -eso es la lección 7- y se decide.

El registro del sistema

journalctl es el registro central de systemd: todo lo que escriben los servicios pasa por ahí. Con cuatro opciones se filtra lo que haga falta.

Las formas útiles de consultarlo

# Seguir en vivo lo que escribe un servicio (Ctrl+C para salir)
sudo journalctl -u nginx -f

# Solo errores, de todo el sistema, desde hoy
sudo journalctl -p err --since today

# Un rango de tiempo concreto
sudo journalctl --since "2026-09-07 09:00" --until "2026-09-07 10:00"

# Lo ocurrido en el arranque anterior (util si se reinicio solo)
sudo journalctl -b -1 -p err

Comprueba que el registro sobrevive a los reinicios. Según cómo esté configurada la máquina, el diario puede guardarse solo en memoria: al reiniciar, desaparece. Y lo que uno necesita leer casi siempre es por qué se reinició.

journalctl --list-boots lo revela en un segundo: si solo aparece el arranque actual, no hay histórico. Se arregla poniendo Storage=persistent en /etc/systemd/journald.conf y reiniciando systemd-journald.

Situaciones frecuentes

Cambié la configuración y el cambio no se aplica

Casi ningún servicio relee su configuración solo. Hay dos formas:

restart lo para y lo arranca -corta las conexiones en curso-. reload le pide releer sin cortar el servicio, y es lo que se usa en producción cuando el servicio lo admite.

Modifiqué el archivo .service y systemd lo ignora

Falta sudo systemctl daemon-reload. systemd tiene sus unidades en memoria y no relee los archivos hasta que se lo pides.

El propio status avisa con un «changed on disk» que es fácil pasar por alto.

El servicio se reinicia solo, en bucle

Muchas unidades traen Restart=always: si el programa muere, systemd lo levanta. Si el fallo es de configuración, entra en bucle.

El registro se llena de arranques y el Active siempre dice pocos segundos. Ahí hay que leer el primer error del ciclo, no el último.

¿Qué servicios hay en esta máquina?

systemctl list-units --type=service --state=running lista lo que está corriendo.

Y systemctl --failed muestra solo lo que falló: es una buena primera comprobación al llegar a un servidor ajeno.

El registro ocupa demasiado disco

Pasa, y contribuye a los discos llenos de la lección 6. journalctl --disk-usage dice cuánto ocupa.

sudo journalctl --vacuum-time=30d deja solo los últimos 30 días.

Cada comando con su efecto

Arrastra cada comando a lo que hace, o toca uno y luego su espacio.

Dice si está vivo, si arranca solo y las últimas líneas de su registro.
Hace que el servicio arranque solo cada vez que el servidor se enciende.
Le pide releer su configuración sin cortar las conexiones en curso.
Muestra el registro filtrado por un servicio concreto.
Obliga a systemd a releer los archivos de unidad que cambiaste en disco.

Compruébalo tú mismo

Arrancaste un servicio con start y funciona. El servidor se reinicia de madrugada y el servicio no vuelve. ¿Por qué?

Un servicio dice active (exited). ¿Qué pasa?

Un servicio no arranca. ¿Cuál es el primer paso?

Lo que sigue

Ya sabes manejar y diagnosticar servicios. La siguiente lección va a los recursos: encontrar qué llenó el disco -la causa número uno de fallos raros-, entender de una vez por qué la memoria siempre parece llena, y qué hacer con un proceso que se comió el servidor.