Tutorial completo del comando journalctl en Linux

Si administras sistemas GNU/Linux a diario, tarde o temprano acabas peleándote con los logs del sistema, servicios y kernel. Antes había que ir saltando entre ficheros en /var/log, pero con la llegada de systemd — gestionar servicios con systemd — el juego ha cambiado: ahora casi todo pasa por el diario o journal, y la llave para manejarlo es el comando journalctl.

En esta guía vas a ver, de forma muy detallada y con ejemplos prácticos, cómo usar journalctl para consultar, filtrar, seguir en tiempo real y limpiar logs, cómo limitar el espacio que ocupan en disco y cómo aprovechar sus filtros avanzados (por servicio, PID, usuario, prioridad, tiempo, kernel, etc.). La idea es que termines con una visión completa, sin tener que andar buscando trozos de información en mil sitios distintos.

Qué es journalctl y qué papel juega en systemd

journalctl es la utilidad de línea de comandos que permite consultar el diario de systemd. Forma parte del ecosistema de systemd, que es el sistema de inicio y gestor de servicios que usan hoy distribuciones como Ubuntu, Debian, Fedora, CentOS/RHEL 7+, Arch Linux y muchas otras.

El componente encargado de recopilar los eventos es el demonio systemd-journald, que recoge mensajes provenientes del kernel, initrd, servicios, unidades de systemd, procesos de usuario y mensajes clásicos de syslog. Todo eso se almacena en un formato binario (no texto plano), lo que facilita búsquedas muy rápidas, filtrado avanzado y múltiples formatos de salida.

A diferencia del enfoque tradicional de tener varios ficheros de log dispersos, el journal actúa como punto centralizado de registro del sistema. Eso permite, por ejemplo, ver en una sola línea temporal los mensajes de Nginx y PHP-FPM, o mezclar mensajes del kernel con los de un servicio concreto para cazar un problema de hardware que afecta a una aplicación.

Otra ventaja del formato binario es que los mismos datos se pueden volcar en distintos formatos según te convenga: estilo syslog clásico, JSON para consumir con herramientas externas, formato export para copias de seguridad o formatos con marcas de tiempo más precisas. No hace falta convertir ficheros porque el diario guarda internamente los eventos con metadatos estructurados.

El diario de systemd puede convivir con un servidor syslog clásico (rsyslog, syslog-ng, etc.) o incluso sustituirlo. Puedes seguir enviando logs a un servidor central vía syslog y, al mismo tiempo, usar journalctl para depurar localmente con toda la potencia de filtros y metadatos que ofrece systemd.

Comprobaciones previas: zona horaria y hora del sistema

Como el journal permite mostrar las marcas de tiempo en hora local o en UTC, conviene tener la zona horaria bien configurada para que no te vuelvas loco al correlacionar eventos. Para esto se usa la herramienta timedatectl, que también forma parte de systemd.

Para listar todas las zonas horarias disponibles en tu sistema puedes ejecutar timedatectl list-timezones, y así localizar la que corresponda a tu ubicación. Una vez localizada, la defines con el comando sudo timedatectl set-timezone ZONA/HORARIA, por ejemplo Europe/Madrid para la capital española.

Si quieres comprobar que todo ha quedado bien, ejecuta simplemente timedatectl status, donde verás datos como hora local, hora universal (UTC), zona horaria activa y estado de sincronización NTP. A partir de ahí, journalctl mostrará por defecto las fechas en tu hora local, lo que hace mucho más cómoda la lectura.

Primer contacto: ver todos los registros del journal

La forma más básica de uso es lanzar journalctl sin argumentos. Al hacerlo, el comando mostrará todas las entradas disponibles en el diario, desde la más antigua hasta la más reciente, utilizando un paginador (típicamente less) para que puedas desplazarte por la salida.

En ese listado verás mensajes del proceso de arranque, kernel, servicios, errores de aplicaciones, sesiones de usuario y un largo etcétera. Si el sistema lleva semanas o meses encendido, es totalmente normal encontrar decenas o cientos de miles de líneas, así que lo primero que comprenderás es la necesidad de filtrar.

El formato por defecto se parece mucho al clásico syslog: fecha, nombre de host, proceso, PID y mensaje. La diferencia importante es que, aunque lo veas en texto, internamente todo está estructurado con campos y metadatos a los que podrás acceder después con diferentes filtros.

Si en algún momento quieres ver las fechas en UTC en lugar de la hora local, puedes añadir al comando el parámetro --utc, y todas las marcas de tiempo se ajustarán en consecuencia sin tocar el contenido original.

Filtrar por arranques y ventanas de tiempo

Una de las cosas más útiles de journalctl es que permite acotar los registros por sesiones de arranque (boots) o por rangos temporales concretos. Esto resulta especialmente práctico en servidores con mucho tiempo de actividad o cuando quieres revisar exactamente qué pasó durante un reinicio concreto.

Mostrar solo el arranque actual

Para centrarte en lo que ha ocurrido desde el último reinicio del sistema, puedes usar el indicador -b. Este parámetro indica a journalctl que muestre solamente las entradas recogidas desde el boot actual:

Comando: journalctl -b

Cuando no filtras por arranque y en el log aparecen varios reinicios, el journal inserta líneas tipo -- Reboot -- para marcar las separaciones entre sesiones. Son muy útiles para orientarte, pero en el día a día lo habitual es limitarse al arranque en curso para depurar problemas actuales.

Ver arranques anteriores y habilitar registro persistente

Si quieres investigar problemas que ocurrieron en boots anteriores, necesitarás que el sistema tenga habilitada la persistencia del journal. En algunas distribuciones viene activada por defecto; en otras, hay que crear el directorio /var/log/journal o tocar la configuración.

La forma más simple de habilitar el almacenamiento persistente es crear dicho directorio con sudo mkdir -p /var/log/journal o bien editar /etc/systemd/journald.conf y establecer en la sección la opción Storage=persistent. A partir de ese momento, los registros se mantendrán entre reinicios.

Para listar todos los arranques de los que el journal tiene constancia, puedes usar journalctl --list-boots. Verás una tabla con un índice relativo (0 para el actual, -1 para el anterior, etc.), el ID único de arranque y el intervalo de fechas de cada sesión.

Si quieres acceder al boot anterior, puedes usar ese índice relativo, por ejemplo journalctl -b -1, o bien pasar directamente el ID de arranque completo, algo útil cuando quieres compartir una referencia exacta en documentación o tickets: journalctl -b ID_DE_BOOT.

Definir ventanas de tiempo personalizadas

Además de por arranques, journalctl permite filtrar por rangos de tiempo arbitrarios, algo imprescindible en servidores que apenas se reinician. Para ello se usan las opciones --since y --until, indicando un momento de inicio y, opcionalmente, uno de fin.

El formato de fecha y hora estándar es YYYY-MM-DD HH:MM:SS, aunque es bastante flexible: si omites la fecha, se asume el día actual; si omites la hora, se toma medianoche (00:00:00); también puedes dejar fuera los segundos.

Ejemplos típicos serían journalctl --since "2015-01-10 17:15:00" para mostrar todo lo ocurrido desde esa fecha y hora, o journalctl --since "2015-01-10" --until "2015-01-11 03:00" para acotar exactamente un intervalo concreto que quizá coincide con una incidencia que te han reportado.

El journal también entiende palabras clave relativas como yesterday, today, tomorrow o now. Además, acepta expresiones como "1 hour ago", lo que te permite consultas del estilo: journalctl --since 09:00 --until "1 hour ago" para revisar una ventana dinámica de tiempo sin andar calculando fechas exactas.

Filtrar por servicio, procesos, usuarios y otros campos

Una vez que dominas los filtros temporales, el siguiente paso es centrar los logs en servicios o componentes concretos. Aquí es donde journalctl se vuelve especialmente potente comparado con revisar archivos de texto a pelo.

Filtrar por unidad de systemd

Probablemente el filtro que más usarás es el de unidad, mediante el parámetro -u. Este permite ver solo los eventos relacionados con un servicio concreto. Por ejemplo, para ver qué está pasando con Nginx puedes ejecutar:

Ejemplo: journalctl -u nginx.service

Lo habitual es combinar esto con filtros de tiempo, por ejemplo journalctl -u nginx.service --since today para ver únicamente lo que ha ocurrido hoy. Así evitas ruido de días anteriores y te centras en el comportamiento reciente del servicio.

Una de las grandes ventajas del journal es que puedes intercalar registros de varias unidades en un único timeline. Si tienes Nginx hablando con PHP-FPM, puedes hacer algo como journalctl -u nginx.service -u php-fpm.service --since today y tendrás los logs de ambos servicios ordenados cronológicamente, muy útil para detectar problemas de comunicación entre ellos.

Filtrar por PID, UID y GID

En servicios que generan muchos procesos hijos, o cuando quieres investigar el comportamiento de un proceso concreto, resulta muy práctico filtrar por ID de proceso (PID). Para ello se usa el campo _PID, que el journal añade automáticamente como metadato:

Filtro: journalctl _PID=8088

De forma similar, si quieres ver todas las entradas generadas por un usuario o grupo determinado, puedes usar los campos _UID y _GID. Por ejemplo, si tu servidor web corre como www-data, primero obtienes su UID con id -u www-data y luego filtras con algo tipo journalctl _UID=33 --since today.

El prefijo de guion bajo indica que son campos añadidos por journald usando información del sistema, no simplemente datos que el proceso haya escrito. Esto hace posible hacer búsquedas muy finas sin necesidad de que la aplicación «se porte bien» formateando sus mensajes.

Si tienes dudas sobre qué campos existen, puedes consultar la página de manual systemd.journal-fields. Y si quieres ver qué valores distintos tiene un campo en tu journal, puedes usar journalctl -F NOMBRE_CAMPO, por ejemplo journalctl -F _GID para listar todos los GID que aparecen en los logs.

Filtrar por ruta de ejecutable

Otra opción interesante es filtrar por ruta de un ejecutable. Si pasas a journalctl una ruta como argumento, te mostrará todas las entradas relacionadas con ese binario, por ejemplo:

Por ruta: journalctl /usr/bin/bash

Normalmente es preferible trabajar con unidades de systemd cuando existen, porque así obtienes también los eventos de procesos hijos y metadatos adicionales, pero para programas que no tienen unidad propia este método puede resultar muy útil.

Ver solo los mensajes del kernel

Los mensajes que tradicionalmente obteníamos con dmesg también están almacenados en el journal. Para filtrarlos sin más historias puedes usar las opciones -k o --dmesg:

Kernel: journalctl -k

Por defecto se muestran los mensajes de kernel del arranque actual, pero puedes usar las mismas opciones de selección de boot que antes, por ejemplo journalctl -k -b -5 para ver los mensajes de kernel de hace cinco arranques.

Filtrar por prioridad o nivel de gravedad

Cuando el log está lleno de información, muchas veces solo te interesa ver errores, alertas o fallos críticos. journalctl permite filtrar por prioridad usando la opción -p, aceptando tanto nombres simbólicos como valores numéricos.

Los niveles que implementa el journal siguen la escala estándar de syslog, de mayor a menor importancia: 0: emergencia, 1: alerta, 2: crítico, 3: error, 4: warning, 5: notice, 6: info, 7: debug. Si ejecutas algo como journalctl -p err -b, verás todos los eventos de nivel error o más graves del arranque actual.

Puedes usar tanto el número como el nombre, por ejemplo journalctl -p 4 o journalctl -p warning, y siempre se mostrarán los mensajes con ese nivel y todos los de prioridad superior, lo que te ahorra tener que combinar varios filtros.

Ajustar la forma en que se muestran los registros

Además de filtrar qué entradas quieres ver, journalctl permite modificar el formato y la presentación de la salida para adaptarla a lo que necesites en cada momento, ya sea lectura interactiva o procesamiento automático por scripts.

Acortar o mostrar la entrada completa

Por defecto, el paginador muestra las líneas del log completas, incluso aunque se desborden hacia la derecha; puedes mover el cursor horizontalmente para ver el contenido entero. Si prefieres que las líneas se corten y aparezcan con puntos suspensivos al final, puedes usar la opción --no-full.

En el otro extremo, si quieres que journalctl muestre todos los datos sin ocultar caracteres no imprimibles, puedes añadir el parámetro -a, algo útil cuando trabajas con escapes o mensajes con formatos raros.

Evitar el paginador y volcar a la salida estándar

Cuando la intención es canalizar los logs hacia otras herramientas (grep, awk, jq…) o redirigirlos a un fichero, el paginador por defecto molesta. Para desactivarlo, basta con usar la opción --no-pager, y todo se imprimirá directamente por la salida estándar.

Gracias a esto puedes encadenar fácilmente comandos como journalctl -u nginx --since today --no-pager | grep 500 o volcar cierta parte del journal a un fichero con journalctl > mensajes.log para analizarlo con calma más tarde.

Elegir el formato de salida: syslog, JSON, export, verbose…

La opción -o permite seleccionar entre varios formatos de salida según lo que vayas a hacer con esa información. Algunos de los formatos más útiles son:

• short: formato por defecto, estilo syslog clásico.
• short-iso: igual que el anterior pero con marcas de tiempo ISO 8601 legibles.
• short-monotonic: añade la marca de tiempo monotónica, útil para ver tiempos relativos desde el arranque.
• short-precise: igual que el estándar pero con precisión de microsegundos.
• cat: muestra solo el campo de mensaje, sin metadatos.
• json: una entrada JSON por línea, genial para consumir con jq u otras herramientas.
• json-pretty: JSON formateado con sangrías para lectura humana.
• json-sse: pensado para eventos enviados por servidor (Server-Sent Events).
• export: formato binario adecuado para exportar o hacer copias de seguridad del journal.
• verbose: muestra todos los campos y metadatos asociados a cada evento, incluidos los internos.

Por ejemplo, para sacar los logs de Nginx del arranque actual en formato JSON listo para parsear, podrías usar algo como journalctl -b -u nginx -o json, o si quieres echarles un vistazo legible antes de pasarlos a otra herramienta, journalctl -b -u nginx -o json-pretty.

Seguir los logs en tiempo real y ver las últimas entradas

En el trabajo diario de administración es muy habitual querer vigilar lo que está pasando en ese mismo momento, por ejemplo mientras reinicias un servicio, reproduces un error o lanzas un despliegue. journalctl incorpora de serie funcionalidades similares a tail.

Mostrar solo las entradas más recientes

La opción -n funciona exactamente igual que tail -n: muestra las últimas N entradas del log. Si no indicas número, se muestran por defecto las 10 últimas líneas:

Últimas: journalctl -n

Si quieres cambiar esa cantidad, basta con añadir el número a continuación, por ejemplo journalctl -n 20 para ver las 20 entradas más recientes. Combinado con otros filtros (por servicio, prioridad, etc.) es perfecto para obtener un vistazo rápido del estado de algo concreto.

Seguir el journal en vivo al estilo tail -f

Para monitorizar los logs en tiempo real, conforme se van escribiendo, puedes usar la opción -f, abreviatura de follow, exactamente igual que en tail -f:

Monitor: journalctl -f

Lo interesante es que puedes combinarlo tanto con filtros por servicio como por prioridad o tiempo. Por ejemplo, puedes seguir solo los errores de un servicio determinado con un comando del tipo journalctl -u apache2 -p err -f, y verás aparecer nuevas entradas a medida que se vayan generando.

Gestión del espacio en disco: tamaño del journal y borrado de logs antiguos

El journal es muy cómodo, pero si lo dejas crecer sin control es fácil que empiece a ocupar una cantidad notable de espacio, sobre todo en servidores con mucha actividad. Afortunadamente, journalctl y systemd-journald ofrecen varias formas de controlar su tamaño.

Comprobar cuánto espacio ocupan los logs

Para ver de un vistazo cuánto espacio de disco están usando actualmente los ficheros del journal, puedes ejecutar:

Informe disco: journalctl --disk-usage

La salida indicará algo del estilo «Journals take up 8.0M on disk», dejándote claro el consumo actual. Esta cifra tiene en cuenta tanto el almacenamiento persistente en /var/log/journal como el volátil en /run cuando no hay persistencia.

Eliminar registros antiguos por tamaño o por tiempo

Si decides que el diario está ocupando demasiado, puedes reducirlo de dos maneras principales usando parámetros de vacuum (disponibles a partir de systemd 218): por tamaño total o por antigüedad.

Con la opción --vacuum-size estableces un límite máximo de tamaño para el conjunto de ficheros del journal. journald irá borrando entradas antiguas hasta que el total se ajuste al límite que indiques, por ejemplo:

Limitar tamaño: sudo journalctl --vacuum-size=1G

La otra vía es usar --vacuum-time, que borra todas las entradas anteriores a un determinado umbral de tiempo. Por ejemplo, si quieres conservar únicamente los logs del último año, podrías ejecutar:

Limitar antigüedad: sudo journalctl --vacuum-time=1years

Ambos métodos pueden combinarse en la configuración de journald para que el sistema se autogestione de forma preventiva sin que tú tengas que ir corriendo cuando el disco se llena.

Configurar límites permanentes en journald.conf

Para controlar de forma fina cómo crece el journal, debes editar el archivo /etc/systemd/journald.conf. Ahí encontrarás varias opciones clave que afectan tanto al almacenamiento persistente como al volátil en /run:

• SystemMaxUse=: limita el espacio máximo de disco que el journal puede usar en almacenamiento persistente.
• SystemKeepFree=: indica cuánto espacio debe dejar libre el journal para otros usos al escribir en almacenamiento persistente.
• SystemMaxFileSize=: define el tamaño máximo de cada fichero individual del journal persistente antes de rotar.
• RuntimeMaxUse=: análogo a SystemMaxUse pero para el almacenamiento volátil en /run.
• RuntimeKeepFree=: equivalente a SystemKeepFree pero para el área volátil.
• RuntimeMaxFileSize=: tamaño máximo de los ficheros individuales del journal en el almacenamiento volátil antes de rotar.

Los valores admiten sufijos como K, M, G o T (kilobytes, megabytes, gigabytes, terabytes), de modo que puedes poner cosas tipo SystemMaxUse=500M sin problema. Tras modificar la configuración, recuerda reiniciar el servicio con algo como sudo systemctl restart systemd-journald para que los cambios surtan efecto.

Ten presente que SystemMaxFileSize y RuntimeMaxFileSize son valores orientativos: el sistema intentará ajustar el tamaño de los ficheros a esos límites, pero no siempre coincidirán exactamente, por lo que al interpretar el número de ficheros tras un vacuum no te sorprendas si algunos difieren ligeramente de la cifra esperada.

Otros usos útiles y buenas prácticas con journalctl

Además de todo lo anterior, journalctl ofrece algunas opciones extra que merece la pena tener a mano para el día a día en administración de sistemas, tanto a nivel de usuario normal como de root o grupos privilegiados (wheel, adm, systemd-journal).

Por ejemplo, es posible filtrar el journal por usuario concreto usando _UID, como hemos visto, combinar filtros de tiempo con servicio y prioridad, o incluso utilizar la opción --grep incorporada para buscar cadenas de texto sin tener que recurrir a un grep externo.

También puedes redirigir directamente la salida del journal a un archivo con algo tan simple como journalctl > mensajes.log, útil para compartir un extracto de logs con un compañero o para adjuntarlo a un reporte sin dar acceso al servidor.

Para quienes gestionan sistemas multiusuario, resulta práctico recordar que cada usuario puede ver por defecto sus propios journals, pero el acceso global a los logs del sistema y de otros usuarios está restringido a administradores, justo para evitar filtraciones de información sensible.

Por último, es bueno tener en mente que systemd y journalctl están muy integrados con otras utilidades del ecosistema, como systemctl para listar y gestionar servicios o timedatectl para ajustar la hora. Aprovechar esa integración te hace la vida mucho más sencilla que ir mezclando sistemas antiguos y nuevos.

Con todo este arsenal de opciones, filtros y configuraciones, journalctl se convierte en una herramienta central para supervisar, depurar y mantener la salud de cualquier sistema Linux basado en systemd, permitiéndote pasar de perseguir logs dispersos a tener una visión estructurada y manejable de todo lo que ocurre en la máquina.