journalctl: el cheat sheet para ver y filtrar logs de Linux

journalctl en una línea: journalctl -u <service> -f sigue el log de un servicio en vivo, journalctl -u <service> -n 100 muestra las últimas 100 líneas, y journalctl --since "1 hour ago" muestra todo lo reciente. Eso cubre el 90 % de los momentos "¿por qué está caído este servicio?". El resto de este cheat sheet son los patrones para copiar y pegar que te ahorran releer el man page a las 2 de la mañana — filtrado por unidad, tiempo, prioridad y arranque, más los comandos de limpieza que evitan que el journal se coma tu disco. Cada comando de abajo funciona tal cual en cualquier distro con systemd (Ubuntu, Debian, Fedora, Arch).

¿Qué es journalctl y por qué no leer directamente /var/log/syslog?

El logging a la antigua escribía archivos de texto plano bajo /var/log — syslog, auth.log, messages. systemd lo reemplazó con el journal: un log binario e indexado, gestionado por systemd-journald. Un grep común no puede leerlo; journalctl es la única puerta de entrada, y a cambio te da filtrado por servicio, tiempo, arranque y severidad sin acrobacias de regex.

El modelo mental es simple: el journal guarda todo, y journalctl es la herramienta de consulta. Un servicio no necesita su propio archivo de log — todo lo que escribe a stdout/stderr mientras corre bajo systemd aterriza en el journal automáticamente. Por eso journalctl -u nginx funciona incluso cuando no tienes idea de dónde nginx configuró su log de errores.

Una advertencia: en algunas instalaciones mínimas el journal es volátil (se guarda en /run y se borra al reiniciar) porque /var/log/journal no existe. Se arregla una sola vez:

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal

¿Cómo veo las últimas 100 líneas de un log?

-n limita la salida a las N líneas más recientes (10 por defecto):

journalctl -n 100                      # las últimas 100 líneas de todo
journalctl -u nginx -n 100             # las últimas 100 líneas de una unidad
journalctl -n 100 --no-pager           # imprimir y salir — perfecto para un pipe

--no-pager importa más de lo que parece: sin él journalctl abre less y tu script, tu pipe o tu one-liner por ssh queda colgado esperando una tecla. Cualquier comando cuya salida vaya a un pipe debería llevarlo.

¿Cómo sigo los logs en vivo, como tail -f?

El flag -f es el tail -f de journalctl — transmite las entradas nuevas a medida que ocurren:

journalctl -f                    # todo, en vivo
journalctl -u sshd -f            # solo el demonio SSH, en vivo
journalctl -u ollama -f -n 50    # en vivo, pero empezando por las últimas 50 líneas

Este es el comando para correr en una segunda terminal mientras reinicias un servicio en la primera: systemctl restart nginx en un panel, journalctl -u nginx -f en el otro, y la causa del crash suele anunciarse sola en segundos. Yo corro exactamente este bucle en mi homelab cada vez que un contenedor o servicio se porta mal.

¿Cómo muestro los logs de un servicio concreto?

-u filtra por unidad de systemd:

journalctl -u nginx                    # una unidad, todo el historial
journalctl -u nginx -u redis           # varias unidades a la vez
journalctl _SYSTEMD_UNIT=nginx.service # la alternativa con coincidencia exacta

Una unidad puede crear unidades auxiliares que se quedan con la salida interesante — una app web que falla a veces loggea el error real bajo otra unidad. Si -u <service> no devuelve nada pero el servicio claramente corre, encuentra primero el nombre real de la unidad:

systemctl list-units --type=service | grep -i <guess>

El mismo patrón -u funciona para timers (systemctl list-timers muestra los nombres) y para servicios de usuario — para todo lo que corre bajo systemd --user añade --user:

journalctl --user -u pipewire -n 50

¿Cómo filtro los logs por fecha?

--since y --until aceptan marcas de tiempo, pero también frases relativas bastante flexibles:

journalctl --since "1 hour ago"
journalctl --since "2026-09-01 09:00" --until "2026-09-01 12:00"
journalctl --since today
journalctl --since yesterday --until now -u cron

Combina una ventana de tiempo con una unidad y tienes el triage del incidente en una línea: "¿qué loggeó la API entre las 09:00 y el momento en que se cayó?". Para una sola máquina, eso es más rápido que cualquier agregador de logs.

¿Cómo muestro solo los errores (o los warnings)?

-p filtra por prioridad, usando los nombres de severidad de syslog:

journalctl -p err -b              # solo errores, desde este arranque
journalctl -p warning..alert -u nginx   # un rango de severidades

Las prioridades en orden descendente: emerg, alert, crit, err, warning, notice, info, debug. Cuando una máquina "actúa raro", journalctl -p err -b --since today es el chequeo de cordura más rápido — responde a "¿algo está fallando de verdad?" sin el ruido de las líneas de info rutinarias.

¿Cómo veo los logs del arranque anterior?

Los servicios que crashean al arrancar producen líneas de log antes de tu arranque actual, y journalctl por defecto solo muestra el actual. -b selecciona arranques:

journalctl -b                 # solo el arranque actual
journalctl -b -1              # el arranque anterior
journalctl -b -1 -u sshd      # por qué murió SSH la última vez
journalctl --list-boots       # índice de los arranques guardados

Es el flag más útil para el escenario "se rompió, lo reinicié y ahora no veo el error" — el error sigue ahí, un arranque atrás.

Referencia rápida: los flags que valen la pena memorizar

Objetivo	Comando
Seguir un servicio en vivo	`journalctl -u <svc> -f`
Las últimas 100 líneas	`journalctl -n 100`
Desde hace una hora	`journalctl --since "1 hour ago"`
Errores de este arranque	`journalctl -p err -b`
Arranque anterior	`journalctl -b -1`
Uso de disco del journal	`journalctl --disk-usage`
Salida legible por máquinas	`journalctl -o json-pretty`
Solo mensajes del kernel	`journalctl -k`

¿Cómo evito que el journal llene mi disco?

Primero mira cuánto cuesta, luego ponle un techo:

journalctl --disk-usage
sudo journalctl --vacuum-size=500M     # conservar los 500 MB más recientes
sudo journalctl --vacuum-time=30d      # conservar los 30 días más recientes

Para hacer el techo permanente, pon SystemMaxUse=500M en la sección [Journal] de /etc/systemd/journald.conf, y luego sudo systemctl restart systemd-journald. Entre el límite de tamaño y el filtro por arranque de arriba, el journal vuelve a ser una herramienta en lugar de una fuga de disco lenta.

journalctl vs dmesg vs /var/log — ¿dónde revisar primero?

journalctl — el comportamiento de apps y servicios. Todo lo que gestiona systemd está aquí, indexado y filtrable. La primera parada por defecto.
journalctl -k / dmesg — kernel y hardware: kills por OOM, resets de USB, errores de disco. Si un proceso murió misteriosamente, busca aquí al OOM killer antes de culpar a la app.
/var/log/<app>/ — solo para apps que hacen su propio logging a archivo (logs de acceso de nginx, PostgreSQL). Aun así, los errores de arranque normalmente también aterrizan en el journal.

El mismo flujo se extiende a los servicios de IA locales — cuando una unidad ollama serve se queda colgada, journalctl -u ollama -n 100 muestra el fallo de carga del modelo de inmediato, como cubre la comparación de Ollama vs LM Studio.

Ese es todo el cheat sheet: -u para la unidad, -f para seguir, -n para líneas, --since para tiempo, -p para severidad, -b para arranques. Seis flags cubren casi cualquier pregunta de logs que una máquina Linux te vaya a hacer.