Servicios y registros con systemd
🎯 Objetivo del módulo Consultar y administrar servicios en distribuciones que usan systemd, y diagnosticar fallos mediante el journal.
Este módulo se aplica a sistemas con systemd. Otras distribuciones o entornos mínimos pueden usar un sistema de inicio distinto.
1. Conceptos fundamentales #
| Concepto | Significado |
|---|---|
| Unidad | recurso administrado por systemd |
| Servicio | unidad que ejecuta y supervisa un proceso |
| Activar (enable) | configurar el inicio automático según las dependencias de la unidad |
| Iniciar (start) | arrancar la unidad en la sesión actual |
| Journal | registro estructurado recopilado por systemd-journald |
Activar e iniciar no son lo mismo.
2. Consultar servicios #
1systemctl status ssh.service 2systemctl is-active ssh.service 3systemctl is-enabled ssh.service
El nombre puede variar entre distribuciones. Por ejemplo, el servidor OpenSSH puede llamarse ssh.service o sshd.service.
Lista servicios cargados y en ejecución:
1systemctl list-units --type=service --state=running
Lista también unidades instaladas que no están cargadas:
1systemctl list-unit-files --type=service
3. Iniciar, detener y reiniciar #
1sudo systemctl start nginx.service 2sudo systemctl stop nginx.service 3sudo systemctl restart nginx.service 4sudo systemctl reload nginx.service
reload pide al servicio que recargue su configuración sin reiniciarse, pero solo funciona si la unidad lo admite.
Si no sabes si admite recarga:
1sudo systemctl reload-or-restart nginx.service
4. Inicio automático #
1sudo systemctl enable nginx.service 2sudo systemctl disable nginx.service
Para activar e iniciar en una sola orden:
1sudo systemctl enable --now nginx.service
Deshabilitar no detiene necesariamente el servicio actual. Para deshabilitarlo y detenerlo:
1sudo systemctl disable --now nginx.service
5. Consultar logs con journalctl #
Logs de una unidad #
1journalctl -u nginx.service
Solo desde el arranque actual #
1journalctl -u nginx.service -b
Seguir nuevos mensajes #
1journalctl -u nginx.service -f
Filtrar por tiempo y prioridad #
1journalctl --since '1 hour ago' 2journalctl -p warning -b
Mostrar las últimas líneas #
1journalctl -u nginx.service -n 50 --no-pager
El acceso a determinados mensajes depende de los permisos del usuario y de la configuración del sistema.
6. Diagnóstico paso a paso #
1systemctl status aplicacion.service 2journalctl -u aplicacion.service -b -n 100 --no-pager 3systemctl cat aplicacion.service
Comprueba después:
- El primer error relevante, no solo el último mensaje.
- Las rutas y permisos de archivos usados por el servicio.
- El usuario con el que se ejecuta.
- Las variables y dependencias declaradas en la unidad.
- Si el puerto ya está ocupado (
ss -ltnp).
7. Cambios en archivos de unidad #
Si se crea o modifica una unidad, systemd debe volver a leer su configuración:
1sudo systemctl daemon-reload 2sudo systemctl restart aplicacion.service
daemon-reload no reinicia por sí mismo los servicios.
Para personalizar una unidad suministrada por un paquete, es preferible crear un drop-in:
1sudo systemctl edit nginx.service
Así se evita editar directamente archivos que una actualización del paquete podría reemplazar.
8. Servicios de usuario #
Algunas unidades pertenecen al usuario y no requieren sudo:
1systemctl --user status mi-servicio.service 2journalctl --user -u mi-servicio.service
No mezcles unidades del sistema con unidades de usuario: tienen gestores, rutas y ciclos de vida diferentes.
9. Errores comunes #
- Confundir
enableconstart. - Reiniciar repetidamente sin leer el journal.
- Editar directamente una unidad instalada por un paquete.
- Usar
daemon-reloadesperando que reinicie el servicio. - Suponer que todas las distribuciones usan systemd o el mismo nombre de unidad.
Resumen del tema
Consulta primero systemctl status, examina después journalctl -u, corrige la causa y solo entonces reinicia. Usa enable --now cuando necesites inicio actual y automático.