Logs de systemd: journalctl en lenguaje sencillo

Casi todo lo que ocurre en el sistema acaba en el journal de systemd. Un servicio no arranca, la máquina se reinició sola, el sitio devuelve un 502 — la respuesta suele estar ya registrada, solo hay que saber cómo preguntar.

Cinco comandos que son suficientes

journalctl -u nginx -n 50 --no-pager      # last 50 lines of one service
journalctl -u nginx -f                    # follow in real time
journalctl -p err -b                      # only errors since boot
journalctl --since "10 min ago"           # everything for the last ten minutes
journalctl -b -1 -e                       # previous boot log, end of file

El último es especialmente valioso después de un reinicio repentino: -b -1 abre la sesión anterior y, al final, puedes ver si fue un kernel panic, el OOM killer en acción o un apagado limpio.

Los niveles en -p: emerg, alert, crit, err, warning, notice, info, debug. El nivel indicado incluye todos los más importantes.

Diagnosticar un servicio que falla

systemctl status myapp
journalctl -u myapp --since today -p warning

systemctl status da el código de salida y las últimas líneas, journalctl da el panorama completo. Fíjate en:

• Main process exited, code=exited, status=1 — la aplicación salió con error por su cuenta, la causa está en la línea de arriba;
• Failed to start ... Permission denied — permisos sobre un archivo, un directorio o un puerto por debajo de 1024;
• Killed process ... (java) total-vm... del kernel — el OOM killer entró en acción, lee Sin memoria;
• Start request repeated too quickly — el servicio está en bucle de fallos, systemd ha dejado de arrancarlo; corrige la causa y ejecuta systemctl reset-failed myapp.

Una lista de todo lo que está roto en el sistema es systemctl --failed.

Filtros que ahorran tiempo

journalctl --since "2026-08-22 03:00" --until "2026-08-22 04:00"
journalctl -u nginx -u php-fpm            # several services at once
journalctl _PID=1432                      # by specific process
journalctl -k                             # only kernel messages
journalctl -u sshd | grep "Failed password" | tail -20

Combínalos con grep, pero recuerda: journalctl sin --no-pager abre un paginador, sal con q.

Evitar que el journal se coma el disco

Por defecto, el journal crece hasta el 10 % de la partición. En VDS-1 con un disco de 40 GB, eso son cuatro gigabytes — notable.

journalctl --disk-usage
journalctl --vacuum-size=200M
journalctl --vacuum-time=14d

El límite permanente está en /etc/systemd/journald.conf:

[Journal]
SystemMaxUse=300M
MaxRetentionSec=1month

Después, systemctl restart systemd-journald.

Errores comunes

• Leer el journal sin -u. El flujo general está saturado de registros de servicios y la línea que necesitas se pierde. Acótalo siempre a un servicio o a un nivel.
• Perder el historial tras un reinicio. Si el directorio /var/log/journal no existe, el journal vive solo en memoria. Créalo: mkdir -p /var/log/journal && systemd-tmpfiles --create --prefix /var/log/journal.
• Buscar ahí errores de aplicaciones. Nginx, PostgreSQL y similares también escriben en sus propios archivos en /var/log. Si el journal está vacío, mira ahí.

Cuando el disco está lleno, journalctl puede negarse a funcionar hasta que se libere espacio. Esta situación se cubre en el artículo Sin espacio en disco.