systemd (Español)/Journal (Español)

From ArchWiki
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Estado de la traducción: esta traducción de systemd/Journal fue revisada el 2019-09-20. Si existen cambios puede actualizarla o avisar al equipo de traducción.

systemd tiene un sistema de registro («log») propio llamado journal. Por tanto, ya no es necesario hacer funcionar el demonio syslog. Para leer el registro, utilice: 

# journalctl

En Arch Linux, el directorio /var/log/journal/ es parte del paquete systemd, y journal (cuando Storage= está definido a auto en /etc/systemd/journald.conf) escribirá en /var/log/journal/. Si usted o algún programa eliminan ese directorio, systemd no lo volverá a crear automáticamente y en su lugar escribirá sus registros en /run/systemd/journal de una manera no persistente. Sin embargo, la carpeta se volverá a crear cuando establezca Storage=persistent y reinicie systemd-journald.service (o reinicie el equipo).

El journald de systemd clasifica los mensajes por #Nivel de prioridad y #Nivel del recurso. La clasificación del registro corresponde al protocolo clásico de Syslog (RFC 5424).

Nivel de prioridad

Se utiliza el código de severidad de syslog (en systemd llamado prioridad) para marcar la importancia de un mensaje RFC 5424 Section 6.2.1.

Valor Severidad Palabra clave Descripción Ejemplos
0 Emergencia emerg El sistema está inutilizable Bug importante del kernel, núcleo de systemd volcado.
Este nivel no debe ser utilizado por las aplicaciones.
1 Alerta alert Debe corregirse inmediatamente El subsistema vital parece no funcionar. Pérdida de datos.
kernel: BUG: unable to handle kernel paging request at ffffc90403238ffc.
2 Crítico crit Condiciones criticas Quiebra, volcado del núcleo. Tales como:
systemd-coredump[25319]: Process 25310 (plugin-containe) of user 1000 dumped core
Error en la aplicación principal del sistema, como X11.
3 Error err Condiciones de error Se informa de error no grave:
kernel: usb 1-3: 3:1: cannot get freq at ep 0x84,
systemd[1]: Failed unmounting /var.,
libvirtd[1720]: internal error: Failed to initialize a valid firewall backend).
4 Advertencia warning Puede indicar que se producirá un error si no se toman medidas. Un sistema de archivos no root tiene solo 1GB libre.
org.freedesktop. Notifications[1860]: (process:5999): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale.
5 Aviso notice Eventos que son inusuales, pero que no presuponen un error. systemd[1]: var.mount: Directory /var to mount over is not empty, mounting anyway. gcr-prompter[4997]: Gtk: GtkDialog mapped without a transient parent. This is discouraged.
6 Informativo info Mensajes de operaciones normales que no requieren ninguna acción. lvm[585]: 7 logical volume(s) in volume group "archvg" now active.
7 Depuración errores debug Información útil para los desarrolladores para depurar errores de la aplicación. kdeinit5[1900]: powerdevil: Scheduling inhibition from ":1.14" "firefox" with cookie 13 and reason "screen".

Si no puede encontrar un mensaje en el nivel de prioridad esperado, puede buscar también un par de niveles por encima y por debajo: estas reglas son recomendaciones y el desarrollador de la aplicación afectada puede tener una percepción diferente de la importancia del problema con respecto a la suya.

Nivel del recurso

Se utiliza un código de recursos de syslog para especificar el tipo de programa que está registrando el mensaje RFC 5424 Section 6.2.1.

Código del recurso Palabra clave Descripción Información
0 kern mensajes del kernel
1 user mensajes a nivel de usuario
2 mail sistema de correo El arcaico POSIX todavía se admite y se usa a veces (para más información mail(1))
3 daemon demonios del sistema Todos los demonios, incluyendo systemd y sus subsistemas
4 auth mensajes de seguridad/autorización También tenga en cuenta los diferentes recursos del código 10
5 syslog mensajes generados internamente por syslogd Para las implementaciones de syslogd (no utilizadas por systemd, consulte el código 3)
6 lpr impresora de línea]] (subsistema arcaico)
7 news subsistema de noticias de la red (subsistema arcaico)
8 uucp subsistema UUCP (subsistema arcaico)
9 demonio para el reloj del sistema systemd-timesyncd
10 authpriv mensajes de seguridad/autorización También tenga en cuenta los diferentes recursos del código 4
11 ftp subsistema FTP
12 - subsistema NTP
13 - auditoría de registro
14 - alerta de registro
15 cron demonio de programación
16 local0 uso local 0 (local0)
17 local1 uso local 1 (local1)
18 local2 uso local 2 (local2)
19 local3 uso local 3 (local3)
20 local4 uso local 4 (local4)
21 local5 uso local 5 (local5)
22 local6 uso local 6 (local6)
23 local7 uso local 7 (local7)

Por lo tanto, son códigos útiles para observar: 0,1,3,4,9,10,15.

Filtrar la salida

journalctl le permite filtrar los resultados por campos específicos. Tenga en cuenta que si hay muchos mensajes para mostrar o el filtrado que hay que hacer abarca mucho tiempo, la salida de esta orden puede retrasarse durante bastante tiempo.

Ejemplos:

  • Mostrar todos los mensajes del arranque: 
    # journalctl -b
    Sin embargo, a veces a uno le interesan no los mensajes actuales, sino los mensajes desde el arranque anterior (por ejemplo, si ocurrió un fallo del sistema irrecuperable). Esto es posible pasando el parámetro -b: journalctl -b -0 muestra los mensajes del arranque actual, journalctl -b -1 muestra los mensajes del arranque anterior, journalctl -b -2 muestra los mensajes desde los dos últimos arranques y así sucesivamente. Véase journalctl(1) para una descripción completa, dado que los argumentos que se pueden pasar a la orden hacen que el filtrado pueda ser mucho más potente.
  • Mostrar todos los mensajes de fecha (y hora opcional): 
    # journalctl --since="2012-10-30 18:17:16"
  • Mostrar todos los mensajes desde hace 20 minutos: 
    # journalctl --since "20 min ago"
  • Seguir los mensajes nuevos: 
    # journalctl -f
  • Mostrar todos los mensajes por un ejecutable específico: 
    # journalctl /usr/lib/systemd/systemd
  • Mostrar todos los mensajes para un proceso específico: 
    # journalctl _PID=1
  • Mostrar todos los mensajes por una unidad específica: 
    # journalctl -u man-db.service
  • Mostrar el búfer del kernel 
    # journalctl -k
  • Mostrar solo mensajes de error, críticos y de prioridad de alerta 
    # journalctl -p err..alert
    También se pueden usar números, journalctl -p 3..1. Si se utiliza un solo número/palabra clave, journalctl -p 3 —también se incluyen todos los niveles de prioridad más altos—.
  • Mostrar el equivalente de auth.log para filtrar en el código de instalación de syslog: 
    # journalctl SYSLOG_FACILITY=10
  • Si el directorio de journal (de manera predeterminada, ubicado en /var/log/journal) contiene una gran cantidad de datos de registro, entonces journalctl puede tardar varios minutos en filtrar la salida. Puede acelerarlo significativamente usando la opción --file para forzar a journalctl a buscar solo en el journal más reciente: 
    # journalctl --file /var/log/journal/*/system.journal -f

Véase journalctl(1), systemd.journal-fields(7) o esta entrada de blog de Lennert para obtener más detalles.

Sugerencia: De forma predeterminada, journalctl trunca las líneas más largas que exceden del ancho de la pantalla, pero en algunos casos, puede ser mejor activar el ajuste en lugar de fracturarlas. Esto puede ser controlado por la variable de entorno SYSTEMD_LESS, que contiene opciones pasadas a less (el paginador predeterminado) y, por defecto, a FRSXMK (consulte less(1) y journalctl(1) para más detalles).

Al omitir la opción S, la salida se ajustará en lugar de truncarla. Por ejemplo, inicie journalctl de la siguiente manera: 

$ SYSTEMD_LESS=FRXMK journalctl
Si desea establecer este comportamiento como predeterminado, exporte la variable desde ~/.bashrc o ~/.zshrc.
Sugerencia: mientras journal se almacena en un formato binario, el contenido de los mensajes almacenados no se modifica. Esto significa que se puede visualizar en forma de strings («cadenas»), por ejemplo, para la recuperación en un entorno que no tiene instalado systemd. Ejemplo de orden: 
$ strings /mnt/arch/var/log/journal/af4967d77fba44c6b093d0e9862f6ddd/system.journal | grep -i message

Límite del tamaño de journal

Si journal se ha creado como permanente (no volátil), el límite de su tamaño se establece con un valor predeterminado correspondiente al 10% del tamaño del sistema de archivos pero limitado a 4 GiB. Por ejemplo, con /var/log/journal alojado en una partición raíz de 20 GiB, esto permitiría almacenar hasta 2 GiB de datos en journal. En una de 50 GiB, tendría un máximo de 4 GiB.

El tamaño máximo del journal permanente puede ser controlado descomentando y modificando la correspondiente línea: 

/etc/systemd/journald.conf
SystemMaxUse=50M

También es posible utilizar el mecanismo de sobrescribir la configuración con fragmentos insertados en lugar de editar el archivo de configuración global. En este caso, no olvide colocar el reemplazo debajo del encabezado de [Journal]: 

/etc/systemd/journald.conf.d/00-journal-size.conf
[Journal]
SystemMaxUse=50M

Reinicie el servicio systemd-journald.service después de cambiar esta configuración para aplicar inmediatamente el nuevo límite.

Vea journald.conf(5) para más información.

Limpiar manualmente archivos journal

Los archivos journal se pueden eliminar globalmente de /var/log/journal/ utilizando por ejemplo rm, o se pueden recortar de acuerdo con varios criterios usando journalctl. Ejemplos:

  • Eliminar los archivos journal archivados hasta que el espacio en disco que utilizan esté por debajo de 100M: 
    # journalctl --vacuum-size=100M
  • Hacer que todos los archivos journal no contengan datos de más de 2 semanas. 
    # journalctl --vacuum-time=2weeks

Vea journalctl(1) para más información.

Journald coexistiendo con syslog

La compatibilidad con una implementación clásica, syslog, no reconocida por journald, se puede proporcionar al permitir que systemd reenvíe todos los mensajes a través del socket /run/systemd/journal/syslog. Para hacer que el demonio syslog funcione con journal, debe vincularse a este socket en lugar de a /dev/log (anuncio oficial).

El journald.conf predeterminado para reenviar al socket es ForwardToSyslog=no para evitar la sobrecarga del sistema, porque rsyslog o syslog-ng tiran de los mensajes de journal por sí mismo.

Vea Syslog-ng#Overview y Syslog-ng#syslog-ng and systemd journal, o rsyslog respectivamente, para obtener detalles sobre la configuración.

Reenviar journald a /dev/tty12

Cree un directorio inclusivo /etc/systemd/journald.conf.d y cree un archivo fw-tty12.conf en él: 

/etc/systemd/journald.conf.d/fw-tty12.conf
[Journal]
ForwardToConsole=yes
TTYPath=/dev/tty12
MaxLevelConsole=info

Depués reinicie systemd-journald.service.

Especificar un journal diferente para visulizar

Puede ser necesario verificar los registros de un sistema inoperativo, arrancado desde un sistema live para recuperar un sistema operativo. En tal caso, se puede montar el disco, por ejemplo en /mnt, y especificar la ruta de journal a través de -D/--directory, así: 

$ journalctl -D /mnt/var/log/journal -xe