Comando journalctl: uso, registros por servicio y limpieza del tamaño del journal

El comando journalctl es la herramienta para elegir y leer en el journal de systemd los registros que dejan los servicios y el kernel. En Linux con systemd, systemd-journald reúne estos registros en el journal. Al leer registros por servicio, tiempo y prioridad en un servidor AlmaLinux 9 y en un servidor Debian 12, una cuenta normal solo veía sus propios registros, y un servidor que guarda el journal en memoria no podía elegir un arranque anterior.

La salida de abajo procede de los dos servidores. Los nombres de host, las cuentas, los ID de arranque, los números de proceso del servidor AlmaLinux y la versión del paquete systemd se cambiaron por valores de ejemplo, y ambos servidores mostraron las horas en UTC.

1️⃣ Cómo usar el comando journalctl y ver los registros recientes

Si ejecutas journalctl sin opciones, el journal se abre en less desde su línea más antigua, así que para ver los registros recientes fija el número de líneas con -n. Si omites el número tras -n, salen 10 líneas.

journalctl -n 3

Oct 28 07:14:06 server1 systemd[1]: session-3017.scope: Deactivated successfully.
Oct 28 07:14:06 server1 systemd[1]: session-3017.scope: Consumed 3.934s CPU time.
Oct 28 07:14:07 server1 sudo[851987]: pam_unix(sudo:session): session closed for user user

Cada línea se compone de la hora, el nombre de host, el programa que dejó el registro con su número de proceso y el mensaje. Al añadir -r se invierte el orden y la línea más reciente sube arriba del todo. En el registro de crond del servidor AlmaLinux, la línea CMDEND escrita en último lugar quedó arriba.

journalctl -r -u crond -n 3

Oct 28 07:01:01 server1 CROND[841384]: (root) CMDEND (run-parts /etc/cron.hourly)
Oct 28 07:01:01 server1 run-parts[841394]: (/etc/cron.hourly) starting 0anacron
Oct 28 07:01:01 server1 CROND[841388]: (root) CMD (run-parts /etc/cron.hourly)

-f no termina tras mostrar la última línea y sigue mostrando las líneas nuevas que llegan. En el servidor Debian 12 se dejó en pantalla la última línea de logger con -q y -t myapp, y se escribieron dos líneas más con logger. Las dos líneas aparecieron justo debajo.

journalctl -q -f -n 1 -t myapp

Oct 28 07:12:46 server2 myapp[347704]: journalctl error test
Oct 28 07:14:35 server2 myapp[347881]: follow line 1
Oct 28 07:14:36 server2 myapp[347877]: follow line 2

-f no se detiene hasta que pulsas Ctrl+C, así que úsalo para vigilar el registro mientras un servicio se reinicia.

En less, las líneas más anchas que la pantalla se cortan por la derecha y la parte cortada se ve con las teclas de flecha. La salida enviada a una tubería o a un archivo no pasa por less. Para mostrarla directamente en la terminal sin less, añade --no-pager.

2️⃣ Registros de journalctl por servicio

Las líneas recientes mezclan registros de muchos servicios, así que para ver el registro de un solo servicio indica el nombre de la unidad con -u. El .service al final del nombre de la unidad se puede omitir.

journalctl -u crond -n 4

Oct 28 06:01:01 server1 CROND[802926]: (root) CMDEND (run-parts /etc/cron.hourly)
Oct 28 07:01:01 server1 CROND[841388]: (root) CMD (run-parts /etc/cron.hourly)
Oct 28 07:01:01 server1 run-parts[841394]: (/etc/cron.hourly) starting 0anacron
Oct 28 07:01:01 server1 CROND[841384]: (root) CMDEND (run-parts /etc/cron.hourly)

Si escribes -u dos veces, los registros de los dos servicios salen mezclados en orden de hora. Al elegir crond y nginx juntos de 08:00 a 08:15 del 18 de octubre en el servidor AlmaLinux, tras cuatro líneas de crond a las 08:01 siguieron dos líneas de nginx reload a las 08:12.

journalctl -u nginx -u crond --since '2026-10-18 08:00' --until '2026-10-18 08:15'

Oct 18 08:01:01 server1 CROND[381522]: (root) CMD (run-parts /etc/cron.hourly)
Oct 18 08:01:01 server1 run-parts[381528]: (/etc/cron.hourly) starting 0anacron
Oct 18 08:01:01 server1 run-parts[381534]: (/etc/cron.hourly) finished 0anacron
Oct 18 08:01:01 server1 CROND[381518]: (root) CMDEND (run-parts /etc/cron.hourly)
Oct 18 08:12:30 server1 systemd[1]: Reloading nginx - high performance web server...
Oct 18 08:12:30 server1 systemd[1]: Reloaded nginx - high performance web server.

systemctl status muestra solo las últimas 10 líneas de registro bajo el estado del servicio, así que los registros anteriores se revisan con journalctl -u. Justo después de ejecutar systemctl restart en un servicio, ejecuta journalctl -u para revisar el registro de arranque.

Los registros que scripts o tareas de cron dejaron con logger se buscan por su etiqueta (identificador), no por una unidad. Tras -t, escribe el mismo nombre que se dio a -t de logger.

logger -t myapp 'journalctl test message'

En el servidor Debian 12, logger no mostró nada en pantalla, y las líneas escritas se encontraron con -t myapp.

journalctl -q -t myapp

Oct 28 07:12:44 server2 myapp[347693]: journalctl test message

-g deja solo las líneas cuyo mensaje contiene un texto concreto. Si escribes el texto todo en minúsculas, no distingue mayúsculas de minúsculas.

journalctl -u crond -g anacron -n 2

Oct 28 07:01:01 server1 run-parts[841394]: (/etc/cron.hourly) starting 0anacron

-n cuenta las líneas antes de que -g las filtre, así que de las dos últimas líneas de crond solo quedó la que contenía anacron.

3️⃣ Registros por rango de tiempo y por arranque

--since y --until fijan el inicio y el final del rango de tiempo que se muestra. Si hay un espacio entre la fecha y la hora, encierra el valor entre comillas simples.

En el servidor AlmaLinux, las últimas 2 horas empezaron con las líneas de crond escritas a las 06:01; abajo están las cuatro primeras.

journalctl -u crond --since '-2h' | head -4

Oct 28 06:01:01 server1 CROND[802930]: (root) CMD (run-parts /etc/cron.hourly)
Oct 28 06:01:01 server1 run-parts[802936]: (/etc/cron.hourly) starting 0anacron
Oct 28 06:01:01 server1 CROND[802926]: (root) CMDEND (run-parts /etc/cron.hourly)
Oct 28 07:01:01 server1 CROND[841388]: (root) CMD (run-parts /etc/cron.hourly)

-b deja solo los registros desde el arranque actual. Para averiguar por qué se reinició un servidor, comprueba primero en la lista de arranques si quedan registros del arranque anterior.

journalctl -b -u crond -n 2

Oct 28 07:01:01 server1 run-parts[841394]: (/etc/cron.hourly) starting 0anacron
Oct 28 07:01:01 server1 CROND[841384]: (root) CMDEND (run-parts /etc/cron.hourly)

--list-boots muestra, para cada arranque que queda en el journal, su número, su ID de arranque y la hora de su primera y su última línea.

journalctl --list-boots

IDX BOOT ID                          FIRST ENTRY                 LAST ENTRY
  0 4f1c2a9be0d34c7a8e6b5d20c1f3a7e9 Sat 2026-10-17 08:29:26 UTC Wed 2026-10-28 07:16:10 UTC

El servidor AlmaLinux no guarda el journal en disco, así que solo tenía un registro de arranque. Por eso -b -1 para el arranque anterior solo dejó un aviso y terminó.

journalctl -b -1

Specifying boot ID or boot offset has no effect, no persistent journal was found.

Los registros de un arranque anterior solo se pueden leer con -b -1 en servidores que guardan el journal en disco (/var/log/journal).

4️⃣ Registros de errores y del kernel con journalctl

-p elige las líneas por la prioridad del registro. Si indicas un nivel, salen ese nivel y todos los más importantes, y el nivel se puede escribir por nombre o por número.

Tras dejar una línea de nivel err con logger y elegir con -p err, la línea de nivel notice con la misma etiqueta (journalctl test message) desapareció y solo quedó la línea err.

logger -t myapp -p user.err 'journalctl error test'; journalctl -q -t myapp -p err

Oct 28 07:12:46 server2 myapp[347704]: journalctl error test

Si unes dos niveles con dos puntos, solo se muestra ese rango. Al elegir warning..err quedan solo los niveles de aviso y de error.

journalctl -q -t myapp -p warning..err

Oct 28 07:12:46 server2 myapp[347704]: journalctl error test

-k deja solo los mensajes del kernel y muestra solo las líneas desde el arranque actual.

journalctl -k -n 3

Oct 26 10:14:25 server1 systemd-rc-local-generator[96245]: /etc/rc.d/rc.local is not marked executable, skipping.
Oct 27 10:47:57 server1 systemd-rc-local-generator[512078]: /etc/rc.d/rc.local is not marked executable, skipping.
Oct 27 11:01:10 server1 systemd-rc-local-generator[520023]: /etc/rc.d/rc.local is not marked executable, skipping.

Las tres últimas líneas de -k en el servidor AlmaLinux eran todas de systemd-rc-local-generator. Estas líneas son mensajes escritos en el búfer de registro del kernel, así que se guardan con _TRANSPORT igual a kernel y también salen con -k.

5️⃣ Formatos de salida de journalctl

-o cambia el formato de cada línea. El valor predeterminado short es casi igual que un archivo syslog, y short-iso cambia la hora al formato ISO 8601 con la zona horaria incluida. Al pasar a short-iso en el servidor AlmaLinux, se añadió +0000 al final de la hora.

journalctl -u crond -n 2 -o short-iso

2026-10-28T07:01:01+0000 server1 run-parts[841394]: (/etc/cron.hourly) starting 0anacron
2026-10-28T07:01:01+0000 server1 CROND[841384]: (root) CMDEND (run-parts /etc/cron.hourly)

cat quita la hora y el nombre de host y muestra solo el mensaje, así que úsalo cuando pases los mensajes a grep o a otro programa.

journalctl -u crond -n 2 -o cat

(/etc/cron.hourly) starting 0anacron
(root) CMDEND (run-parts /etc/cron.hourly)

json y json-pretty muestran los campos guardados en el journal como nombres y valores. Al elegir campos con --output-fields, los campos de cursor, hora e ID de arranque siempre los acompañan. Incluso eligiendo solo cuatro campos en el servidor Debian 12, aparecieron también __CURSOR, _BOOT_ID y dos campos de hora.

journalctl -q -t myapp -n 1 -o json-pretty --output-fields=MESSAGE,PRIORITY,SYSLOG_IDENTIFIER,_PID

{
	"__REALTIME_TIMESTAMP" : "1793171676664200",
	"_PID" : "347877",
	"SYSLOG_IDENTIFIER" : "myapp",
	"MESSAGE" : "follow line 2",
	"__CURSOR" : "s=2a6f0c1d9e8b47a3b5c4d3e2f1a0b9c8;i=1a2b3;b=b7e3d1a04c9f4e2a8d6c5b1f0e2a9c47;m=17cf8fe36f5;t=65ee150cf1188;x=1f2e3d4c5b6a7980",
	"_BOOT_ID" : "b7e3d1a04c9f4e2a8d6c5b1f0e2a9c47",
	"PRIORITY" : "5",
	"__MONOTONIC_TIMESTAMP" : "1636264982261"
}

6️⃣ Ubicación del journal y limpieza de su tamaño

Que el journal esté en memoria o en disco lo decide el valor Storage= de journald.conf. El valor predeterminado auto lo guarda en disco si existe la carpeta /var/log/journal y en memoria (/run/log/journal) si no existe.

El servidor AlmaLinux no tenía la carpeta /var/log/journal, así que su journal solo estaba en /run/log/journal.

ls -ld /var/log/journal /run/log/journal

ls: cannot access '/var/log/journal': No such file or directory
drwxr-sr-x+ 4 root systemd-journal 80 Oct 17 08:30 /run/log/journal

El servidor Debian 12 tenía las dos carpetas, y su journal se iba acumulando en disco.

ls -ld /var/log/journal /run/log/journal

drwxr-sr-x+ 2 root systemd-journal   40 Oct  9 08:43 /run/log/journal
drwxr-sr-x+ 4 root systemd-journal 4096 Sep 24 12:52 /var/log/journal

Para conservar los registros tras reiniciar, cambia Storage= en journald.conf a persistent y reinicia systemd-journald. Según el manual oficial, la carpeta /var/log/journal se crea automáticamente cuando hace falta. En este artículo no se cambió la configuración.

Un journal guardado en disco es como la caja negra de un avión, que se saca y se lee después de un incidente.

--disk-usage muestra el tamaño total de los archivos del journal archivados y de los que se están usando. En una cuenta normal del servidor Debian 12, con el aviso [Hint] de arriba oculto con -q, el resultado fue una sola línea: 6.6M.

journalctl -q --disk-usage

Archived and active journals take up 6.6M in the file system.

El tamaño máximo del journal guardado en disco se fija con SystemMaxUse=. Si no se indica un valor, el límite es el 10% del tamaño del sistema de archivos (hasta 4G), y en el journald.conf del servidor Debian 12 había escrito 50M.

grep -v '^#' /etc/systemd/journald.conf | grep -v '^$'

[Journal]
SystemMaxUse=50M

Para reducir enseguida los journals antiguos, fija el tamaño que se conserva con --vacuum-size o el periodo que se conserva con --vacuum-time. Las dos órdenes borran archivos del journal, así que en este artículo no se ejecutaron.

journalctl --vacuum-size=200M

--vacuum-size=200M borra los archivos del journal archivados empezando por los más antiguos hasta que el tamaño total queda por debajo de 200M.

journalctl --vacuum-time=2weeks

--vacuum-time=2weeks borra los archivos archivados que solo contienen líneas de hace más de 2 semanas.

vacuum solo borra los archivos archivados y deja los que se están usando, así que incluso después de ejecutarlo el número de --disk-usage puede no bajar hasta el tamaño indicado.

Los registros de texto de /var/log los escribe rsyslog, que funciona aparte de journald. Por eso los dos registros se leen y se gestionan de forma distinta.

7️⃣ Permisos de lectura y opciones del comando journalctl

🔲 Permisos de lectura

Al ejecutar journalctl con una cuenta que no es root, aparece arriba un mensaje [Hint] y solo se ven los registros que dejó esa cuenta. Al buscar los registros de nginx con una cuenta normal en el servidor Debian 12, tras el aviso solo salió [-- No entries --].

journalctl -u nginx -n 5

Hint: You are currently not seeing messages from other users and the system.
      Users in groups 'adm', 'systemd-journal' can see all messages.
      Pass -q to turn off this notice.
-- No entries --

Según id -nG, esta cuenta pertenecía a un solo grupo, y no estaba en los grupos adm ni systemd-journal que menciona el aviso.

id -nG

user

El manual oficial explica que las cuentas de los grupos systemd-journal, adm y wheel pueden leer todo el journal. adm y wheel traen además otros permisos que fija la distribución, y wheel a menudo permite también tareas de administración, así que para una cuenta que solo lee registros lo adecuado es el grupo systemd-journal.

usermod -aG systemd-journal user

La orden usermod que añade el grupo no se ejecutó en este artículo. Tras añadir el grupo, vuelve a iniciar sesión y comprueba los grupos con id -nG. Una cuenta con permisos de administrador también ve todos los registros si ejecuta sudo journalctl.

El mensaje [Hint] se oculta con -q. Aun así, con -q los registros visibles siguen siendo solo las líneas que dejó esa cuenta. --user lee el journal de usuario de esa cuenta y solo funciona en servidores que guardan el journal en disco. En el servidor Debian 12, que guarda el journal en disco, aparecieron las líneas de systemd y de logger de esa cuenta.

journalctl --user -n 3

Oct 28 07:12:35 server2 systemd[347665]: Reached target default.target - Main User Target.
Oct 28 07:12:35 server2 systemd[347665]: Startup finished in 181ms.
Oct 28 07:12:44 server2 myapp[347693]: journalctl test message

🔲 Opciones del comando journalctl

📌 Opciones principales: resultados de este artículo

📎 Otras opciones: según el manual oficial

🔲 Simulador del comando journalctl

En el simulador de abajo puedes escribir tú mismo los comandos para ver registros recientes, registros por servicio, rangos de tiempo, prioridades y formatos de salida.

🔢 FAQ & contenido recomendado

🧭 Comandos de información · configuración del sistema: contenido recomendado 8 artículos · 2 referencias

🗂️ Comandos de información · configuración del sistema

▸📂 Información del sistema4

📄 Información de CPU · RAM · disco · SO 📄 uname · versión del kernel 📄 Comando free 📄 Comando uptime

▸📂 Configuración2

📄 Comando timedatectl 📄 Comando localectl

▸📂 Registros2

📄 logrotate 📄 Comando journalctl

▸🪐 Referencias2

📡 journalctl(1) — systemd 252 📡 journald.conf(5) — systemd 252

Linux · Información del sistema

Cómo comprobar la CPU en Linux: comandos para RAM, disco y SO

En Linux, el número de núcleos de CPU sale enseguida con una línea: [nproc].

Ver artículo →Artículo actual

Linux · Información del sistema

Comandos para comprobar la versión del kernel Linux y cómo ver la versión de la distribución

Al administrar Linux, a veces hay que comprobar la versión del kernel de Linux y la versión de la distribución.

Ver artículo →Artículo actual

Linux · Información del sistema

Comando free de Linux: comprobar el estado de la memoria

El comando free de Linux muestra el uso de memoria y la memoria libre del servidor, leyendo la información de memoria de /proc/meminfo.

Ver artículo →Artículo actual

Linux · Información del sistema

Comando uptime de Linux (tiempo de actividad del servidor & carga media de 1, 5 y 15 minutos)

El comando uptime de Linux consulta la carga media del sistema y el tiempo que lleva encendido el servidor.

Ver artículo →Artículo actual

Linux · Configuración

Sincronizar la hora del servidor Linux: timedatectl (CentOS 7 o posterior)

En Linux hace falta ajustar la fecha y la hora porque, si la hora es incorrecta mientras el servidor funciona, las horas de los datos de la BD, de los registros y de los accesos al servidor web pueden no coincidir.

Ver artículo →Artículo actual

Linux · Configuración

[Linux] Comando localectl

Desde CentOS 7, muchos comandos se ofrecen de forma integrada.

Ver artículo →Artículo actual

Linux · Registros

Logrotate en Linux: concepto y configuración

Logrotate de Linux, como indica la expresión "rotar los registros", es la unión de log y rotate.

Ver artículo →Artículo actual

Linux · Registros

Comando journalctl: uso, registros por servicio y limpieza del tamaño del journal

El comando journalctl es la herramienta para elegir y leer en el journal de systemd los registros que dejan los servicios y el kernel, y en Linux con systemd, systemd-journald reúne estos registros en el journal.

Ver artículo →Artículo actual

📡journalctl(1) — systemd 252 📡journald.conf(5) — systemd 252

ℹ️ Aviso de afiliados
El contenido de este sitio incluye enlaces de afiliado. Cuando un visitante compra un producto o servicio a través de uno de ellos, el sitio recibe una comisión del vendedor. El importe que paga el comprador^{(baja durante las promociones ↓)}no aumenta. Los precios, descuentos y existencias publicados corresponden al momento de redacción y pueden variar, así que confírmalos con el vendedor antes de comprar. Los productos se eligen y evalúan con criterios propios, y las comisiones no influyen en el orden ni en el contenido de las reseñas.