journalctl en una página — tail, filtro, seguimiento

■ espacio · carril de prosa

LOS SEIS, EN TARJETAS

la escalera -p, descendente — journalctl -p warning..alert acepta un rango · -p err es el caballo de batalla

¿POR QUÉ NO LEER SIMPLEMENTE /var/log/syslog?

El logging Linux de la vieja escuela escribía archivos de texto plano bajo /var/log — syslog, auth.log, messages. systemd replaced that with systemd lo sustituyó por the journal: un log binario e indexado gestionado por . Plain grep cannot read it; journalctl es la única puerta de entrada, y a cambio obtienes filtrado por servicio, tiempo, arranque y severidad sin malabares de regex.

El modelo mental: el journal lo almacena todo, y journalctl lo consulta. Un servicio no necesita su propio archivo de log — todo lo que escribe en stdout/stderr bajo systemd aterriza en el journal automáticamente. Un volatile (guardado en /run, borrado al reiniciar) porque /var/log/journal no existe. Arréglalo una vez:

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

verifica: ls /var/log/journal → el directorio existe — los arranques se acumulan en vez de borrarse

LÍNEAS, SEGUIMIENTO, UNIDADES

-n limita la salida a las N líneas más recientes (por defecto 10). --no-pager importa más de lo que parece: sin él journalctl abre less y tu script, tubería o one-liner ssh se queda colgado esperando una tecla — cualquier comando que encadenes debería llevarlo.

journalctl -n 100                      # last 100 lines of everything
journalctl -u nginx -n 100             # last 100 lines from one unit
journalctl -n 100 --no-pager           # print and exit — perfect for piping

es el is journalctl's tail -f de journalctl — emite las entradas nuevas a medida que ocurren. Es el comando que debes correr en un segundo terminal mientras reinicias un servicio en el primero: systemctl restart nginx en un panel, journalctl -u nginx -f en el otro, y la causa del crash se anuncia sola en segundos.

journalctl -f                    # everything, live
journalctl -u sshd -f            # just the SSH daemon, live
journalctl -u ollama -f -n 50    # live, but start with the last 50 lines

filtra por unidad systemd — una, varias, o la alternativa de coincidencia exacta: filters by systemd unit — one, several, or the exact-match alternative:

journalctl -u nginx                    # one unit, all history
journalctl -u nginx -u redis           # several units at once
journalctl _SYSTEMD_UNIT=nginx.service # exact match

-u <servicio> no muestra nada pero el servicio claramente corre? Las unidades pueden engendrar unidades auxiliares que se quedan la salida interesante — una web app que falla a veces loguea en la systemctl list-units --type=service | grep -i <guess>. El mismo patrón vale para timers (systemctl list-timers muestra nombres) y para todo lo que corre bajo systemd --user, añade --user: journalctl --user -u pipewire -n 50.

TIEMPO Y SEVERIDAD

--since and --until aceptan marcas de tiempo, pero también admiten frases relativas flexibles. Empareja una ventana con una unidad y tienes el triaje del incidente en una línea — "¿qué hizo

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

-p filtra por prioridad usando la escalera syslog mostrada arriba. Cuando una máquina "actúa raro", journalctl -p err -b --since today es la comprobación de cordura más rápida — responde "¿está fallando algo de verdad?" sin el ruido de las líneas info de rutina.

journalctl -p err -b                    # errors only, since this boot
journalctl -p warning..alert -u nginx   # a range of severities

ARRANCQUES

El crash que reiniciaste sigue en el journal. Los servicios que crashean al arrancar producen líneas de log antes de tu arranque actual, y journalctl silenciosamente solo muestra el actual. -b selecciona arranques — es la opción más útil para "se rompió, lo reinicié y ahora no veo el error":

journalctl -b                 # current boot only
journalctl -b -1              # previous boot
journalctl -b -1 -u sshd      # why SSH died last time
journalctl --list-boots       # index of stored boots

EL DISCO

Comprueba lo que cuesta el journal y ponle techo — un vacuum ahora, una línea de config para siempre:

journalctl --disk-usage
sudo journalctl --vacuum-size=500M     # keep newest 500 MB
sudo journalctl --vacuum-time=30d      # keep newest 30 days

Para hacer el techo permanente, pon SystemMaxUse=500M bajo la sección [Journal][Journal] en /etc/systemd/journald.conf, luego . Entre el techo de tamaño y el filtro de arranque, el journal sigue siendo una herramienta y no una lenta fuga de disco.

08¿QUÉ LOG PRIMERO?

• journalctl — comportamiento de aplicaciones y servicios. Todo lo que gestiona systemd está aquí, indexado y filtrable. Primera parada por defecto.
• journalctl -k / — núcleo y hardware: kills OOM, resets USB, errores de disco. Si un proceso murió misteriosamente, busca el OOM killer aquí antes de culpar a la app. — kernel and hardware: OOM kills, USB resets, disk errors. If a process died mysteriously, look for the OOM killer here before blaming the app.
• — solo para apps que hacen su propio logging a archivo (logs de acceso de nginx, PostgreSQL). Aun así, los errores de arranque suelen acabar en el journal. — only for apps that do their own file logging (nginx access logs, PostgreSQL). Even then, startup errors usually still land in the journal.

El mismo flujo se extiende a los servicios de IA locales — cuando una unidad ollama serve se atasca, journalctl -u ollama -n 100 muestra el fallo de carga del modelo al instante. Esa es toda la chuleta: -u para unidad, -f para seguir, -n para líneas, --since para tiempo, -p para severidad, -b para arranques. Seis opciones cubren casi cualquier pregunta de log que una caja Linux te haga — y cuando la pregunta es por qué un servicio systemd no arranca, estas

fin de la chuleta · nada descargado · todo local