¿Qué es journalctl con systemd en Linux y cómo funciona?

En los últimos tiempos hemos tenido cierta polémica a raíz de la incorporación de systemd en la mayoría de sistemas operativos GNU Linux. Para quien no lo conozca se trata de un conjunto de demonios –daemons-, bibliotecas y herramientas enfocadas a la administración del sistemas, que interactúan con el núcleo o kernel, de nuestro sistemas operativo del Ñu y el Pingüino. La idea es que sustituya al sistema de inicio heredado de los viejos sistemas UNIX. Esto último no ha gustado a muchos administradores ; en cualquier caso hablar de ello no es el fin de este artículo.

Una de las ventajas principales de systemd son las que participan en el proceso y registro del sistema. Por norma general para ver los registros o logs de un servicio del sistema tenemos que consultar, el directorio /var/log y echar un ojo a sus diferentes registros. La solución que encuentra systemd es una administración centralizada de todos los procesos del kernel y los usuarios. El sistema que recopila y administra estos registros es conocida como “journal” o diario.

Dicho diario se implementa con el demonio llamado journald. Este se encarga de manejas todos los mensajes producidos por el kernel, initrd, servicios, etcétera. Vamos a ver entonces como usar la utilidad journalctl, que nos permitirá acceder y manipular dichos datos.

¿Por qué una utilidad centralizada cómo journalctl?

Ya sabéis que soy administrador de sistemas, en mi día a día tengo que consultar continuamente los registros, bien porque ha fallado algún servicio, bien para ver los registros de envío de correo o incluso cuando nuestro sistema produce un “crash” Todo ello es algo farragoso, ya que son registros ubicados en ficheros diferentes y no siempre ubicados en /var/log. Pienso por ejemplo en las aplicaciones Java a medida que ubican sus registros dentro de la carpeta /opt.

Tengo que admitir que la idea de Journalctl me seduce, aunque de momento dicha utilidad, por ejemplo en CentOS y RHEL, sólo está disponible a partir de la versión 7 (la que ha adaptado systemd) A priori al interactuar con los datos utilizando una sola utilidad, los administradores pueden mostrar dinámicamente los datos de registro según sus necesidades.

Empezando a utilizar Journalctl

Antes de nada nos tenemos que asegurar que la zona horaria del sistema esté bien definida. Para ello la systemd incorpora la herramienta timedatectl que nos ayudará a comprobar la hora zona horaria.

Para comprobar, por ejemplo, las zonas horarias disponibles:

En mi caso, para ver la zona horaria de la capital de España, sería:

Una vez hayamos localizado la zona que nos interesa, la podemos definir utilizando el parámetro set time-zone

Podemos comprobar la configuración actual, escribiendo:

En mi caso, en la máquina virtual que estoy utilizando para el artículo:

Ya tenemos la zona horaria definida correctamente, continuemos.

La manera por defecto de ver los logs del demonio journald, es utilizando el comando journalctl, aquí os dejo una muestra:

Con el resultado:

Es cierto, son cientos y miles de datos, al final este resultado no se diferencia de los registros habituales de syslog. Vamos a ver como especificar lo que queremos consultar, en concreto.

Empezemos consultando los registros que se han producido desde el registro más reciente, utilizando el parámetro -b

El propio journalctlnos inserta una línea indicando que el registro es desde un reinicio del sistema.

Por otra parte el comando los muestra información del arranque actual. Lo cierto es que lo ideal es que también podamos consultar información de reinicios anteriores. Algunas distribuciones esta opción la llevan por defecto. Mi máquina virtual utiliza CentOS 7, por lo que para habilitar la información de arranque de manera persistente, debemos modificar el fichero de configuración, ubicado en /etc/systemd/journald.confg, y cambiar el parámetro “Storage” por “persistent”.

Sería de la siguiente manera:

Una vez hecho esto, al reiniciar, ya podemos ver el registro de reinicios del sistema:

Si queremos volver a utilizar el comando journalctl y que también nos muestre los logs del reinicios anterior, podemos añadir, en este caso, los parámetros journalctl –b -1, de esta manera tendremos los datos el estado actual y lo anteriores al reinicio.

Lo cierto es que con el paso del tiempo se pueden acumular cantidades ingentes de datos, por lo que estaría bien filtrar por fecha. Para ello podemos utilizar los pámetros --since y --until, para mostrar entradas anteriores o siguientes a una fecha, como se observa en el ejemplo.

Con el resultado:

También se incluyen otros parámetros, como por ejemplo ver los logs del día anterior:

O los de hace dos horas:

Muchas posibilidades, como podemos ver.

Consultar registros de servicios

Entramos en la parte interesante, también podemos ver los registros de un servicios en concreto (unidades). El servidor que estoy utilizando lo utilizo para probar contenedores con Docker, así que vamos a echar un vistazo a su log.

Con el siguiente resultado:

También podemos ver los logs sólo de hoy:

Otros usos

También podemos ver los registros de un proceso y sus hijos, agrupados en un número de PID

También podemos consultar los mensajes del núcleo o kernel del sistema:

Al igual que en otros casos anteriores, añadiendo el parámetro -b, veremos los mensajes únicamente del inicio actual:

Como pasa con el comando tail, utilizando el parámetro -n podemos mostrar únicamente un número de líneas, como por ejemplo:

Con el resultado:

También podemos filtrar el resultado por prioridad de mensaje, teniendo en cuanta las prioridades:

• “emerg” (0)
• ”alert” (1)
• “crit” (2)
• “warning” (4)
• “notice” (5)
• ”info” (6)
• “debug” (7)

Por ejemplo:

Con el resultado:

Visualizar registros de dispositivos

Una opción muy útil es que nos permite visualizar sólo los registros de un dispositivo en concreto, como una unidad de disco. Por ejemplo:

Con el resultado, en mi caso:

Incluso podemos ver el espacio ocupado por los diferentes logs, esto me lo he sacado de la web del replicante 😉

Una muestra del resultado en la máquina virtual:

Podemos limitar el tamaño, si este fuera excesivo, modificando el fichero antes comentado /etc/systemd/journald.conf.

Aquí acaba el artículo, espero que en algún momento os sea de utilidad.

Me he servido para el artículo de la información contenida en:

Fuentes | Digitalocean.com | LaMiradaDelReplicante.com

Respecto a los derechos de la imagen de portada | Flickr