GNU/Linux >> Tutoriales Linux >  >> Linux

Uso de diarios systemd para solucionar problemas transitorios

La determinación de problemas puede ser tanto un arte como una ciencia y, a veces, parece que incluso un poco de magia puede ser útil. Todo el mundo se ha encontrado con situaciones en las que no se ha podido reproducir un fallo informado, lo que siempre es frustrante tanto para el usuario como para el administrador del sistema. Incluso los electrodomésticos y los automóviles pueden ser obstinados y negarse a fallar cuando aparece el técnico de servicio.

Dejando de lado el antropomorfismo, los administradores de sistemas tienen algunas herramientas que pueden mostrar lo que ha estado sucediendo en sus computadoras Linux con diversos grados de granularidad. Hay herramientas, como top, htop, looks, sar, iotop, tcpdump, traceroute, mtr, iptraf-ng, df, du y muchas más, todas las cuales pueden mostrar el estado actual de un host y varias de las cuales pueden producir registros. de varios niveles de detalle.

Si bien estas herramientas se pueden usar para encontrar problemas continuos, no son particularmente útiles para problemas transitorios o aquellos que no tienen síntomas observables directamente, al menos no observables hasta que ocurra algún problema importante y posiblemente catastrófico.

Una herramienta importante que uso para la determinación de problemas son los registros del sistema y, con systemd, los diarios del sistema. El diario systemd es siempre una de las primeras herramientas a las que recurro cuando resuelvo un problema, especialmente los problemas que no parecen ocurrir cuando estoy mirando. Me tomó mucho tiempo al comienzo de mi carrera de administrador de sistemas darme cuenta de la gran cantidad de información en los archivos de registro, y este descubrimiento mejoró en gran medida mi velocidad para resolver problemas.

Ya has visto algunos usos del journalctl comando en muchos de los artículos anteriores de esta serie. En este artículo, exploraré algunos detalles sobre systemd journal, cómo funciona y formas de usar journalctl para localizar e identificar problemas.

Acerca de las revistas

El propósito de cualquier registro o diario es mantener un historial secuenciado en el tiempo de las actividades normales de los servicios y programas que se ejecutan en un host y registrar cualquier error o mensaje de advertencia que ocurra. Los mensajes de registro solían mantenerse en archivos separados en /var/log , generalmente un archivo para el núcleo y archivos separados para la mayoría de los servicios que se ejecutan en el host. Desafortunadamente, la gran cantidad de archivos de registro podría dispersar la información necesaria y retrasar el descubrimiento de la causa raíz de un problema. Esto podría llevar mucho tiempo cuando intenta determinar qué estaba sucediendo en un sistema cuando ocurrió un error.

El antiguo /var/log/dmesg El archivo se usaba generalmente para el núcleo, pero ese archivo fue descontinuado hace varios años a favor del uso de dmesg comando para mostrar la misma información e integrar esos mensajes (y más) en el /var/log/messages expediente. Esta fusión de otros registros en los mensajes El archivo ayudó a acelerar la determinación de problemas al mantener gran parte de los datos en un solo archivo, pero todavía había muchos servicios cuyos registros no estaban integrados en los mensajes más centrales. archivo.

El diario systemd está diseñado para recopilar todos los mensajes en una estructura única y unificada que puede mostrar una imagen completa de todo lo que sucedió en un sistema en y alrededor de un momento o evento específico. Debido a que los eventos, independientemente de la fuente, están en un lugar y en una secuencia de tiempo, es posible ver de un vistazo todo lo que sucede en un punto específico o rango de tiempo. En mi opinión, este es uno de los principales beneficios de systemd journaling.

Acerca del diario systemd

El servicio de registro en diario systemd es implementado por el systemd-journald demonio. Según el systemd-journald página man:

systemd-journald es un servicio del sistema que recopila y almacena datos de registro. Crea y mantiene revistas estructuradas e indexadas basadas en la información de registro que se recibe de una variedad de fuentes:

  • Mensajes de registro del kernel, a través de kmsg
  • Mensajes de registro del sistema simples, a través de libc syslog(3) llamar
  • Mensajes de registro del sistema estructurado a través de la API nativa de Journal, consulte sd_journal_print(3)
  • Salida estándar y error estándar de las unidades de servicio. Para obtener más detalles, consulte a continuación.
  • Registros de auditoría, que se originan en el subsistema de auditoría del kernel

El demonio recopilará implícitamente numerosos campos de metadatos para cada mensaje de registro de forma segura e infalsificable. Ver systemd.journal-fields(7) para obtener más información sobre los metadatos recopilados.

Los datos de registro recopilados por la revista se basan principalmente en texto, pero también pueden incluir datos binarios cuando sea necesario. Los campos individuales que componen un registro almacenado en el diario pueden tener un tamaño de hasta 2^64-1 bytes.

Cambios de configuración

Más recursos de Linux

  • Hoja de trucos de los comandos de Linux
  • Hoja de trucos de comandos avanzados de Linux
  • Curso en línea gratuito:Descripción general técnica de RHEL
  • Hoja de trucos de red de Linux
  • Hoja de trucos de SELinux
  • Hoja de trucos de los comandos comunes de Linux
  • ¿Qué son los contenedores de Linux?
  • Nuestros últimos artículos sobre Linux

El daemon de diario de systemd se puede configurar usando /etc/systemd/journald.conf expediente. Para muchos hosts, este archivo no necesita ningún cambio porque los valores predeterminados son bastante razonables. Mire su journald.conf presente su archivo ahora, si aún no lo ha hecho.

Los cambios de configuración más comunes que podría considerar especificarían el tamaño máximo del archivo de diario, la cantidad de archivos de diario más antiguos y los tiempos máximos de retención de archivos. La razón principal para realizar esos cambios sería reducir el espacio de almacenamiento utilizado por la revista si tiene un dispositivo de almacenamiento pequeño. En un entorno de misión crítica, es posible que también desee reducir la cantidad de tiempo entre la sincronización de los datos del diario almacenados en la memoria RAM con el dispositivo de almacenamiento.

El journald.conf La página del manual tiene más detalles.

Controversias sobre el formato de datos

Una de las controversias que rodean a systemd es el formato binario en el que se almacenan los contenidos de las revistas. Algunos argumentos en contra de systemd se basan en que el diario de systemd se almacena en formato binario. Esto parecería ser contrario a la filosofía de Unix/Linux de usar texto ASCII para datos, que es un argumento que la gente usa para justificar su disgusto por systemd. Por ejemplo, Doug McIlroy, el inventor de las pipas, dijo:

"Esta es la Filosofía de Unix:Escribir programas que hagan bien una cosa. Escribir programas para trabajar juntos. Escribir programas para manejar flujos de texto, porque esa es una interfaz universal". —Doug McIlroy, citado en el libro de Eric S. Raymond The Art of Unix Programming

Sin embargo, estos argumentos parecen estar basados ​​en al menos un concepto erróneo parcial porque la página del manual establece claramente que los datos "están principalmente basados ​​en texto", aunque permite formas de datos binarios. El creador del kernel de Linux, Linus Torvalds, quien siempre tiene claros sus sentimientos, dijo:

"En realidad, no tengo opiniones particularmente sólidas sobre systemd en sí. He tenido problemas con algunos de los principales desarrolladores que creo que son demasiado arrogantes con respecto a los errores y la compatibilidad, y creo que algunos de los detalles de diseño son una locura (yo no me gustan los registros binarios, por ejemplo), pero esos son detalles, no grandes problemas". —Linus Torvalds, citado en "Linus Torvalds and others on Linux's systemd" de ZDNet en 2014

Los archivos de diario systemd se almacenan en uno o más subdirectorios de /var/log/journal . Inicie sesión en un sistema de prueba en el que tenga acceso de root y cree /var/log/journal el directorio de trabajo actual (PWD). Enumere los subdirectorios allí, elija uno y conviértalo en PWD. Puede consultar estos archivos de varias formas. Empecé con el stat comando (tenga en cuenta que los nombres de los archivos de diario en su host serán diferentes a los míos):

 [root @ testvm1 3bccd1140fca488187f8a1439c832f07] # stat system@7ed846aadf1743139083681ec4042037-0000000000000001-0005a99c0280fd5f.journal 
del archivo:system@7ed846aadf1743139083681ec4042037-0000000000000001-0005a99c0280fd5f.journal
Tamaño:8388608 Bloques:16392 IO Block:4096 regulares archivo
Dispositivo:fd04h/64772d    Inodo:524384      Enlaces:1
Acceso:(0640/-rw-r-----)  Uid:(    0/    root)   Gid:(  190/systemd-journal )
Acceso:2020-07-13 08:30:05.764291231 -0400
Modificar:2020-07-04 07:33:52.916001110 -0400
Cambio:2020-07-04 07:33:52.916001110 -0400
 Nacimiento:-
[root@testvm1 3bccd1140fca488187f8a1439c832f07]#

El archivo de diario se identifica como un archivo "regular", que no es especialmente útil. El archivo El comando lo identifica como un archivo de "diario", pero ya lo sabe. Mire dentro del archivo con el dd dominio. El siguiente comando envía el flujo de datos de salida a STDOUT; es posible que desee canalizarlo a través de less localizador:

[root@testvm1 3bccd1140fca488187f8a1439c832f07]# dd if=system@7ed846aadf1743139083681ec4042037-0000000000000001-0005a99c0280fd5f.journal | menos

9�P1�8��9_SOURCE_MONOTONIC_TIMESTAMP=191726���/��P��9MESSAGE=Inode-cache hash table entradas:1048576 (orden:11, 8388608 bytes , lineal)�hx
9�P1�p�9��/��P�b��9��9_SOURCE_MONOTONIC_TIMESTAMP=191825�pdXY�7p�9��9MESSAGE=mem auto-init :stack:off, heap alloc:off, heap free:off�i��
��(n�O���@Y�    ���Z �82���7X�8 �����8��DZR�����8<~B�4�<� �8tM˞8$����8��Ж��h9�&������9 �����`@�9�pdXY�7b�ͺ��WV��9��9_SOURCE_MONOTONIC_TIM
ESTAMP=234745����4�h@�9��9MESSAGE=Memoria:12598028K/12963384K disponible (14339K código kernel, 2406K rwdata, 8164K rodata, 2468K init, 5072K b
ss, 365356K reservado, 0K cma-reservado)�j��(n�O�@Y�  ��� �]��m�82���7X�8�������8��DZR�����8<~B�4�<� �8tM˞8$��8�� Æ��h9�&�����9�ͺ��WV��9���
4�hbB�a��^��9��9_SOURCE_MONOTONIC_TIMESTAMP=234758��3�� �9��9MESSAGE=random:get_random_u64 llamado desde __kmem_cache_create+0x3e/0x610 wi
th crng_init=0�k���(n�O���@Y�   ����j��� �82�7X��8C�X�Y"��8�������8��DZR���8<~B�4�<� �8tM˞8$� �8� �Ж�à�9B���a�9�3��b�8�ȭ���9h�9_SO�9h�9MESSAGE=SLUB:HWalign=64, Order=0-3, MinObjects =0, CPU=4, Nodos=1�l����(n�O���@Y�  ������z��X�82���7X�8������ �8��DZR�����8<~B�4�<� �8tM˞
b�(+I)�x�9�9_SOURCE_MONOTONIC_TIMESTAMP=235444r�%/p��9�9 MENSAJE =Aislamiento de tablas de páginas de kernel/usuario:activado�m����(n�O���@Y�     ��k��B0��8
2���7X�8��� ��8��DZR�����8<~B�4�<� �8tM˞8$��8��Ж��h9�&��8�9�(+ I) Ҡ�9�%/pb8O{ W���8�9��9_SOURCE_MONOTONIC_TIMESTAMP=235464u�N`�FP    M��9
��9MESSAGE=ftrace:asignación de 41361 entradas en 162 páginas�n ����(n�O���@Y�

Incluso esta pequeña porción del flujo de datos del dd El comando muestra una mezcla interesante de texto ASCII y datos binarios. Otra herramienta útil son las strings comando, que simplemente muestra todas las cadenas de texto ASCII contenidas en un archivo e ignora los datos binarios:

 [root @ testvm1 3bccd1140fca488187f8a1439c832f07] # cuerdas system@7ed846aadf174313908368Ec042037-0000000000000001-0000000000000001-0000000000000001-0005f.journal 

Mensaje =Linux versión 5.7.6-201.fc32.x86_64 ([email protected] .fedoraproject.org) (gcc versión 10.1.1 20200507 (Red Hat 10.1.1-1) (GC
C), GNU ld versión 2.34-3.fc32) #1 SMP lunes 29 de junio 15:15:52 UTC 2020
MENSAJE
_BOOT_ID=6e944f99ebd9405984090f829a927fa4
_BOOT_ID
_MACHINE_ID=3bccd1140fca488187f8a1439c832f07
_MACHINE_ID
_HOSTbo>_testvm1.org
_HOSTbo>_thvSTNAME
>PRIORIDAD=6
MENSAJE=Línea de comando:BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.7.6-201.fc32.x86_64 root=/dev/mapper/VG01-root ro resume=/dev/mapper/ VG01-swap rd.lv
m.lv=VG01/root rd.lvm.lv=VG01/swap rd.lvm.lv=VG01/usr selinux=0
MESSAGE=x86/fpu:Compatibilidad con XSAVE función 0x001:'x87 registros de coma flotante'
MESSAGE=x86/fpu:función XSAVE compatible 0x002:'registros SSE'
MESSAGE=x86/fpu:función XSAVE compatible 0x00 4:'Registros AVX'
Z_g3;
MESSAGE=x86/fpu:xstate_offset[2]: 576, xstate_sizes[2]: 256
Z_g3;
MESSAGE=x86/fpu :Funciones xstate habilitadas 0x7, el tamaño del contexto es de 832 bytes, usando formato 'estándar'.
MESSAGE=mapa de RAM físico proporcionado por BIOS:
`k2X
MESSAGE=BIOS-e820:[mem 0x0000000000000000 -0x000000000009fbff] USABLE
MENSAJE =BIOS-E820:[MEM 0x00000000000009FC00-0X00000000000009FFFFF] Reservado
Mensaje =BIOS-E820:[MEM 0x00000000000F0000-0X0000000000000FFFFFF] Reservado
PYLM
MENSAJE =BIOS -e820:[MEM 0x0000000000100000-0x0000000000dffffff] USABLE
MENSAJE =BIOS-E820:[MEM 0x0000000000DFF0000-0X0000000000DFFFFFFF] ACPI Datos
Mensaje =BIOS-E820:[MEM 0x00000000FEC00000-0X0000000000FEC00FFF] Reservado
Mensaje =BIOS-E820:[MEM 0x00000000FEE00000-0X00000000FEE00FFF] Reservado
Mensaje =BIOS-E820:[MEM 0x0000000000FFFC0000-0x0000000000FFFFFFFF] Reservado
Mensaje =BIOS-E820:[MEM 0x0000000100000000-0x00000003373FFFFFFFF] Utilizable

Estos datos pueden ser interpretados por humanos, y este segmento en particular se ve muy similar al flujo de datos de salida del dmesg dominio. Te dejaré explorar más por tu cuenta, pero mi conclusión es que los archivos de diario son claramente una mezcla de texto binario y ASCII. Esa combinación hace que sea engorroso usar las herramientas tradicionales de Linux basadas en texto para extraer datos utilizables. Pero hay una forma mejor que brinda muchas posibilidades para extraer y ver datos de diarios.

Acerca de journalctl

El diarioctl El comando está diseñado para extraer información utilizable de los diarios systemd utilizando criterios potentes y flexibles para identificar los datos deseados. Los artículos anteriores de esta serie han descrito journalctl , y hay más que saber.

Revisaré un poco primero y comenzaré con algunos conceptos básicos en caso de que no haya leído los artículos anteriores o simplemente necesite un repaso.

Puedes usar el journalctl Comando sin opciones ni argumentos para ver el diario systemd que contiene toda la información de registro y diario:

[root@testvm1 ~]# journalctl
-- Los registros comienzan el lunes 2020-06-08 07:47:20 EDT, terminan el jueves 2020-07-16 10:30:43 EDT. --
8 de junio 07:47:20 kernel testvm1.both.org:Linux versión 5.6.6-300.fc32.x86_64 ([email protected]) (gcc versión 10.0>
08 de junio 07:47:20 testvm1.both.org kernel:línea de comandos:BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.6.6-300.fc32.x86_64 root=/dev/mapper/VG01-root ro>
08 de junio 07:47:20 kernel testvm1.both.org:x86/fpu:Compatibilidad con la función XSAVE 0x001:'x87 registros de punto flotante'
08 de junio 07:47:20 kernel testvm1.both.org:x86/fpu:Compatibilidad con la función XSAVE 0x002:'Registros SSE'
8 de junio 07:47:20 testvm1.both.org kernel:x86/fpu:Compatibilidad con la función XSAVE 0x004:'Registros AVX'
8 de junio 07:47:20 kernel testvm1.both.org:x86/fpu:xstate_offset[2]: 576, xstate_sizes[2]: 256
8 de junio 07:47:20 kernel testvm1.both.org:x86/fpu :Funciones xstate habilitadas 0x7, el tamaño del contexto es de 832 bytes, utilizando el formato 'estándar'. :47:20 núcleo testvm1.both.org:BIOS-e820:[mem 0x00 00000000000000-0x000000000009fbff] utilizable

16 de julio 09:51:00 testvm1.both.org NetworkManager[760]:  [1594907460.1765] dhcp4 (enp0s3):opción de enrutadores_solicitados    => '1 '
16 de julio 09:51:00 testvm1.both.org NetworkManager[760]:  [1594907460.1765] dhcp4 (enp0s3):opción rutas_estáticas_solicitadas => '1'
16 de julio 09:51:00 testvm1.both.org NetworkManager[760]:  [1594907460.1765] dhcp4 (enp0s3):opción solicitada_subnet_mask => '1'
16 de julio 09:51:00 testvm1.both.org NetworkManager[760]:  [1594907460.1765] dhcp4 (enp0s3):opción request_time_offset => '1'
16 de julio 09:51:00 testvm1.both.org NetworkManager[760]:  [1594907460.1766] dhcp4 (enp0s3):opción solicitada_wpad       => '1'
16 de julio 09:51:00 testvm1.both.org NetworkManager[760]:  [1594907460.1766] dhcp4 (enp0s3):opción enrutadores              => '192.168.0.2>
16 de julio 09:51:00 testvm1.both.org NetworkManager[760]:  [1594907460.1766] dhcp4 (enp0s3):opción subred_ mask          => '255.255.255>
16 de julio 09:51:00 testvm1.both.org NetworkManager[760]:  [1594907460.1766] dhcp4 (enp0s3):estado cambiado extendido -> extendido
16 de julio 09:51:00 testvm1.both.org systemd[1]:Iniciando el servicio de distribución de secuencias de comandos de Network Manager...
16 de julio 09:51:00 testvm1.both.org systemd[1]:Administrador de red iniciado Script Dispatcher Service.
16 de julio 09:51:00 testvm1.both.org audit[1]:SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=NetworkManager-dispatcher com>
16 de julio 09:51:10 testvm1.both.org systemd[1]:NetworkManager-dispatcher.service:Succeeded.
16 de julio 09:51:10 testvm1.both.org audit[1]:SERVICE_STOP pid =1 uid=0 auid=4294967295 ses=4294967295 msg='unit=NetworkManager-dispatcher comm>
16 de julio 09:59:13 testvm1.both.org systemd[1]:Iniciando dnf makecache...
16 de julio 09:59:13 testvm1.both.org audit[1]:SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=dnf-makecache comm="systemd">
16 de julio 09:59:13 testvm1.both.org audit[1]:SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=dnf-makecache comm="systemd" e>
16 de julio 09:59:13 testvm1.both.org systemd[1]:dnf-makecache.service:Correcto.
16 de julio 09:59:13 testvm1.both.org systemd[1]:Finalizó dnf makecache.
16 de julio 09 :59:14 testvm1.both.org dnf[378549]:Caché de metadatos actualizado recientemente.
16 de julio 10:00:42 testvm1.both.org systemd[1]:Iniciando herramienta de contabilidad de actividad del sistema...
16 de julio 10:00:42 testvm1.both.org systemd[1]:sysstat-collect.service:Succeeded.
16 de julio 10:00:42 testvm1.both.org audit[1]:SERVICE_START pid =1 uid=0 auid=4294967295 ses=4294967295 msg='unit=sysstat-collect comm="systemd>
16 de julio 10:00:42 testvm1.both.org systemd[1]:herramienta de contabilidad de actividad del sistema finalizada .
16 de julio 10:00:42 testvm1.both.org audit[1]:SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=sysstat-collect comm="systemd">
16 de julio 10:01:01 testvm1.both.org CROND[378562]:(raíz) CMD (run-parts /etc/cron.hourly)
16 de julio 10:01:01 testvm1.both.org run-parts[378565]:(/etc/cron.hourly) a partir de 0anacron
16 de julio 10:01:01 testvm1.both.org run-parts[378571]:(/etc/cron.hourly) terminó 0anacron

También puede mostrar explícitamente los mismos datos el dmesg presenta el comando. Abra dos sesiones de terminal una al lado de la otra y emita el dmesg comando en uno y el siguiente comando en el otro:

[raíz@testvm1 ~]# journalctl --dmesg 

La única diferencia que debería ver es el formato de hora. El dmesg El comando está en un formato monótono que muestra la cantidad de segundos desde que se inició el sistema. El diarioctl la salida tiene un formato de fecha y hora. La opción monótona corta muestra el tiempo desde el arranque:

[root@testvm1 ~]# journalctl --dmesg -o short-monotonic
-- Los registros comienzan el lunes 2020-06-08 07:47:20 EDT, finalizan el lunes 2020-07-20 13 :01:01 EDT. --
[    0.000000] testvm1.both.org kernel:Linux versión 5.7.6-201.fc32.x86_64 ([email protected]) (gcc versión 10.1.>
[    0.000000 ] testvm1.both.org kernel:línea de comando:BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.7.6-201.fc32.x86_64 root=/dev/mapper/VG01-root ro r>
[    0.000000] kernel testvm1.both.org:x86/fpu:función XSAVE compatible 0x001:'registros de coma flotante x87'
[    0.000000] kernel testvm1.both.org:x86/fpu:función XSAVE compatible 0x002:'registros SSE'
[    0.000000] testvm1.both.org kernel:x86/fpu:Compatibilidad con la función XSAVE 0x004:'Registros AVX'
[    0.000000] testvm1.both.org kernel:x86/fpu:xstate_offset[2]: 576 , xstate_sizes[2]: 256
[    0.000000] testvm1.both.org kernel:x86/fpu:características de xstate habilitadas 0x7, el tamaño del contexto es 832 bytes, utilizando el formato 'estándar'.

[    0.000002] testvm1.both.org kernel:clocksource:kvm-clock:mask:0xffffffffffffffff max_cycles:0x1cd42e4dffb, max_idle_ns:881 5905914>
[    0.000005] testvm1.both.org kernel:tsc:Procesador de 2807,988 MHz detectado
[    0.001157] testvm1.both.org kernel:e820:actualización [mem 0x00000000-0x00000fff] utilizable ==> reservado
[    0.001159] kernel testvm1.both.org:e820:eliminar [mem 0x000a0000-0x000fffff] usable
[    0.001162] kernel testvm1.both.org:last_pfn =0x24ec00 max_arch_pfn =0x400000000
[    0.001173] kernel testvm1.both.org:rangos variables de MTRR deshabilitados:
[    0.001173] kernel testvm1.both.org:deshabilitado
[    0.001174] testvm1.both.org kernel:x86/PAT:MTRR deshabilitados, omitiendo la inicialización de PAT también.
[    0.001176] testvm1.both.org kernel:CPU MTRR en blanco - sistema virtualizado.
[ 0.001179] testvm1.both.org kernel:x86/PAT:Configuración [0-7]:WB  WT  UC- UC  WB  WT  UC- UC  
[    0.001182] testvm1.both.org kernel:last_pfn =0xdfff0 max_arch_pfn =0x400000000
[    0.001238] prueba kernel vm1.both.org:se encontró la tabla SMP MP en [mem 0x0009fff0-0x0009ffff]
[    0.081068] kernel testvm1.both.org:RAMDISK:[mem 0x34194000-0x360c1fff]
[    0.081088] testvm1. kernel de both.org:ACPI:Verificación de suma de verificación de tabla temprana deshabilitada

[   34.037575] kernel de testvm1.both.org:16:43:32.734466 main     6.1.10_Fedora r138449 iniciado. Nivel detallado =0
[   34.042209] testvm1.both.org kernel:16:43:32.739032 principal     vbglR3GuestCtrlDetectPeekGetCancelSupport:compatible (#1)
[   55.746944] testvm1.both.org kernel:e1000:enp0s3 NIC Link is Up 1000 Mbps Full Duplex, control de flujo:RX
[   55.747738] testvm1.both.org kernel:IPv6:ADDRCONF(NETDEV_CHANGE):enp0s3:el enlace está listo

líneas 624 -681/681 (FIN)

El diarioctl El comando tiene muchas opciones, incluido el -o (salida) con varias subopciones que le permiten seleccionar un formato de hora y fecha que cumpla con diferentes conjuntos de requisitos. He enumerado la mayoría de ellos a continuación, junto con una breve descripción que amplié o modifiqué del journalctl página de manual Tenga en cuenta que la principal diferencia entre la mayoría de estos es el formato de la fecha y la hora, y la otra información sigue siendo la misma.

formatos de hora y fecha journalctl

  • breve: Este es el formato predeterminado y genera una salida que se asemeja más al formato de los archivos syslog clásicos, mostrando una línea por entrada de diario. Esta opción muestra los metadatos del diario, incluido el tiempo monótono desde el arranque, el nombre de host completo y el nombre de la unidad, como el kernel, DHCP, etc.
    20 de julio 08:43:01 testvm1.both Kernel .org:Entradas de tabla hash de caché de inodo:1048576 (orden:11, 8388608 bytes, lineal) 
  • corto-completo:  Este formato es muy similar al predeterminado, pero muestra marcas de tiempo en el formato --since= y --hasta= opciones aceptan. A diferencia de la información de marca de tiempo que se muestra en el modo de salida breve, este modo incluye información sobre el día de la semana, el año y la zona horaria en la salida y es independiente de la configuración regional.
    Mon 2020-06-08 07:47:20 EDT testvm1.both.org kernel:x86/fpu:Compatibilidad con la función XSAVE 0x004:'Registros AVX' 
  • ISO corto: El formato iso corto es muy similar al predeterminado, pero muestra marcas de tiempo de reloj de pared ISO 8601.
    2020-06-08T07:47:20-0400 testvm1.both.org kernel:kvm-clock :Usando msrs 4b564d01 y 4b564d00 
  • corto-iso-preciso:   Este formato es el mismo que el iso corto, pero incluye una precisión completa de microsegundos.
    2020-06-08T07:47:20.223738-0400 kernel testvm1.both.org:arranque del kernel paravirtualizado en KVM 
  • corto-monótono:   Muy similar al valor predeterminado, pero muestra marcas de tiempo monótonas en lugar de marcas de tiempo de reloj de pared.
    [    2.091107] testvm1.both.org kernel:ata1.00:ATA-6:VBOX HARDDISK, 1.0, max UDMA/ 133 
  • corto-preciso:  Este formato también es similar al predeterminado, pero muestra las marcas de tiempo de syslog clásicas con una precisión de microsegundos. 0x000000000009ffff] reservado
  • Unix abreviado:  Como el predeterminado, pero muestra los segundos transcurridos desde el 1 de enero de 1970, UTC en lugar de las marcas de tiempo del reloj de pared ("hora Unix"). La hora se muestra con una precisión de microsegundos.
    1591616840.232165 testvm1.both.org kernel:tcp_listen_portaddr_hash entradas de la tabla hash:8192 
  • gato: Genera una salida muy concisa que solo muestra el mensaje de cada entrada del diario sin metadatos, ni siquiera una marca de tiempo.
    ohci-pci 0000:00:06.0:irq 22, io mem 0xf0804000 
  • detallado: Este formato muestra la estructura de datos completa para todos los elementos de entrada con todos los campos. Esta es la opción de formato que es más diferente de todas las demás.
    Mon 2020-06-08 07:47:20.222969 EDT [s=d52ddc9f3e8f434b9b9411be2ea50b1e;i=1;b=dcb6dcc0658e4a8d8c781c21a2c6360d7f;m=242d7f;m=242d7f t=5a7912c6148f9;x=8f>
        _SOURCE_MONOTONIC_TIMESTAMP=0
        _TRANSPORT=kernel
        PRIORITY=5
        SYSLOG_FACILITY=0
        SYSLOG_IDENTIFIER=kernel
        MESSAGE=Linux versión 5.6.6-300.fc32.x86_64 ([email protected]) (gcc versión 10.0.1 20200328 (Red Hat 10.0.1-0>
        _BOOT_ID=dcb6dcc0658e4a8d8c781c21a2c6360d _=ID MACHINE 3bccd1140fca488187f8a1439c832f07
        _HOSTNAME=testvm1.both.org

Otras opciones, disponibles con -o opción, permite exportar los datos en varios formatos, como binario o JSON. También encuentro el -x opción iluminante porque puede mostrar mensajes explicativos adicionales para algunas entradas de diario. Si prueba esta opción, tenga en cuenta que puede aumentar considerablemente el flujo de datos de salida. Por ejemplo, la información adicional para una entrada como:

[    4.503737] testvm1.both.org systemd[1]:Inicio de comprobación del sistema de archivos en /dev/mapper/VG01-root...
[    4.691555] testvm1.both.org systemd-fsck[548] :raíz:limpio, 1813/327680 archivos, 48555/1310720 bloques
[    4.933065] testvm1.both.org systemd[1]:Comprobación del sistema de archivos finalizada en /dev/mapper/VG01-root.

se expande a esto:

[    4.503737] testvm1.both.org systemd[1]:Iniciando la verificación del sistema de archivos en /dev/mapper/VG01-root...
-- Asunto:Un trabajo de inicio para la unidad systemd-fsck-root .service ha comenzado a ejecutarse
-- Definido por:systemd
-- Soporte:https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Se ha iniciado la ejecución de un trabajo de inicio para la unidad systemd-fsck-root.service.
--
-- El identificador del trabajo es 36.
[    4.691555] testvm1.both.org systemd -fsck[548]:raíz:limpio, 1813/327680 archivos, 48555/1310720 bloques
[    4.933065] testvm1.both.org systemd[1]:Comprobación del sistema de archivos finalizada en /dev/mapper/VG01-root.
-- Asunto:Un trabajo de inicio para la unidad systemd-fsck-root.service ha finalizado correctamente
-- Definido por:systemd
-- Soporte:https://lists.freedesktop. org/mailman/listinfo/systemd-devel
--
-- Un trabajo de inicio para la unidad systemd-fsck-root.service ha finalizado correctamente.
--
-- El el identificador de trabajo es 36

Hay algo de información nueva aquí, pero creo que el principal beneficio es que la información está contextualizada para aclarar los breves mensajes originales hasta cierto punto.

Restringiendo la búsqueda

La mayoría de las veces, no es necesario ni deseable enumerar todas las entradas del diario y buscarlas manualmente. A veces busco entradas relacionadas con un servicio específico y otras veces busco entradas que ocurrieron en momentos específicos. El diarioctl El comando proporciona potentes opciones que le permiten ver solo los datos que le interesa encontrar.

Comience con --list-boots opción, que enumera todos los arranques durante el período de tiempo en que existen entradas de diario. Tenga en cuenta que el journalctl.conf El archivo puede especificar que las entradas del diario se descarten después de que alcancen una cierta antigüedad o después de que el espacio del dispositivo de almacenamiento (HDD/SSD) ocupado por los diarios alcance una cantidad máxima especificada:

[root@testvm1 ~]# journalctl --list-boots 
-10 dcb6dcc0658e4a8d8c781c21a2c6360d Lun 2020-06-08 07:47:20 EDT—Lun 2020-06-08 07:53:05 EDT
 -9 7d61951a85f445c5946774aaae8bc2a4 Vie 2020-07-03 15:50:06 EDT—Vie 2020-07-03 18:21:23 EDT
 -8 1b3a847577e544b4a2679fe576b62206-08 EDT 1—07-203 Vie 202 Vie 2020-07-03 22:10:54 EDT
 -7 5fef01a3568743af99118107ca6f61ae Vie 2020-07-03 22:18:41 EDT—Sáb 2020-07-04 06:50:19 EDT
 -6 6E944F99EBD9405984090F829A927FA4 SAT 2020-07-04 07:33:25 EDT-SAT 2020-07-04 07:58:59 EDT
-5 EC8B0C81CA4744B1BAD071BDEF432959 SAT 2020-07-04 08:12:06 EDT-SAT 2020-07 -04 09:12:47 EDT
 -4 cb173ec716824e21b87ccf6cb43a9a99 Sábado 04-07-2020 10:19:53 EDT—Sábado 2020-07-04 11:31:03 EDT
 -3 4fe354a8931944096203 Sábado-3a 04-07 07:59:58 EDT—Dom 2020-07-05 09:39:30 EDT
 -2 06fb81f1b29e4f68af9860844668446c Lun 2020-07-06 06:27:05 EDT—Lun 2020-07-13 08:50:06 EDT
 -1 33dbf8e6b9de4113a591c4f487d0ac37 lun 2020-07-13 04:50:33 EDT— Jue 2020-07-16 13:49:32 EDT
  0 75c9b70913934748b5396b3b172bee50 Lun 2020-07-20 08:43:01 EDT—Vie 2020-07-24 12:44:06 EDT

El ID de inicio más reciente aparece en la parte inferior; es el número hexadecimal aleatorio largo. Puede usar estos datos para ver los diarios de un arranque específico. Esto se puede especificar usando el número de compensación de arranque en la columna más a la izquierda o el UUID en la segunda columna. Este comando muestra el diario de la instancia de arranque con el desplazamiento de -2 —el segundo arranque anterior al actual:

[root@testvm1 ~]# journalctl -b -2
-- Los registros comienzan el lunes 2020-06-08 07:47:20 EDT, finalizan el viernes 2020-07-24 12:44:06 EDT. --
6 de julio 06:27:05 kernel testvm1.both.org:Linux versión 5.7.6-201.fc32.x86_64 ([email protected]) (gcc versión 10.1>
Jul 06 06:27:05 testvm1.both.org kernel:Command line:BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.7.6-201.fc32.x86_64 root=/dev/mapper/VG01-root ro>
Jul 06 06:27:05 testvm1.both.org kernel:x86/fpu:Supporting XSAVE feature 0x001:'x87 floating point registers'
Jul 06 06:27:05 testvm1.both.org kernel:x86/fpu:Supporting XSAVE feature 0x002:'SSE registers'

Or you could use the UUID for the desired boot. The offset numbers change after each boot, but the UUID does not:

[root@testvm1 ~]# journalctl -b 06fb81f1b29e4f68af9860844668446c 

The -u option allows you to select specific units to examine. You can use a unit name or a pattern for matching, and you can use this option multiple times to match multiple units or patterns. In this example, I used it in combination with -b to show chronyd journal entries for the current boot:

[root@testvm1 ~]# journalctl -u chronyd -b
-- Logs begin at Mon 2020-06-08 07:47:20 EDT, end at Sun 2020-07-26 09:10:47 EDT. --
Jul 20 12:43:31 testvm1.both.org systemd[1]:Starting NTP client/server...
Jul 20 12:43:31 testvm1.both.org chronyd[811]:chronyd version 3.5 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCD>
Jul 20 12:43:31 testvm1.both.org chronyd[811]:Frequency -0.021 +/- 0.560 ppm read from /var/lib/chrony/drift
Jul 20 12:43:31 testvm1.both.org chronyd[811]:Using right/UTC timezone to obtain leap second data
Jul 20 12:43:31 testvm1.both.org systemd[1]:Started NTP client/server.
Jul 20 12:44:00 testvm1.both.org chronyd[811]:Selected source 192.168.0.52
Jul 20 12:44:00 testvm1.both.org chronyd[811]:System clock TAI offset set to 37 seconds
Jul 20 12:44:00 testvm1.both.org chronyd[811]:System clock wrong by 1.412227 seconds, adjustment started
Jul 20 12:44:01 testvm1.both.org chronyd[811]:System clock was stepped by 1.412227 seconds
[root@testvm1 ~]#

Suppose you want to look at events that were recorded between two arbitrary times. You can also use -S (--since ) and -U (--until ) to specify the beginning and ending times. The following command displays journal entries starting at 15:36:00 on July 24, 2020, through the current time:

[root@testvm1 ~]# journalctl -S "2020-07-24 15:36:00" 

And this command displays all journal entries starting at 15:36:00 on July 24, 2020, until 16:00:00 on July 25:

[root@testvm1 ~]# journalctl -S "2020-07-24 15:36:00" -U "2020-07-25 16:00:00" 

This command combines -S , -U , and -u to give journal entries for the NetworkManager service unit starting at 15:36:00 on July 24, 2020, until 16:00:00 on July 25:

[root@testvm1 ~]# journalctl -S "2020-07-24 15:36:00" -U "2020-07-25 16:00:00" -u NetworkManager 

Some syslog facilities, such as cron, auth, mail, daemon, user, and more, can be viewed with the --facility opción. You can use --facility=help to list the available facilities. In this example, the mail facility is not the Sendmail service that would be used for an email service, but the local client used by Linux to send email to root as event notifications. Sendmail actually has two parts, the server, which (for Fedora and related distributions) is not installed by default, and the client, which is always installed so that it can be used to deliver system emails to local recipients, especially root:

[root@testvm1 ~]# journalctl --facility=mail 

The journalctl man page lists all the options that can be used to narrow searches. The table below summarizes some of the options I use most frequently. Most of these options can be used in various combinations to further narrow a search. Refer to my previous article Analyzing systemd calendar and timespans for details on creating and testing timestamps, as well as important tips like using quotes around timestamps.

Options to narrow searches of the journal

Other interesting options

The journalctl program offers some other interesting options, as well. These are useful for refining the data search, specifying how the journal data is displayed, and managing the journal files.

Additional interesting journalctl options

Option Description
--list-boots This displays a list of boots. The information can be used to show journal entries only for a particular boot.
-b [offset|boot ID] This specifies which boot to display information for. It includes all journal entries from that boot through shutdown or reboot.
--facility=[facility name] This specifies the facility names as they're known to syslog. Use --facility=help to list the valid facility names.
-k , --dmesg These display only kernel messages and are equivalent to using the dmesg command.
-S , --since [timestamp] These show all journal entries since (after) the specified time. They can be used with --until  to display an arbitrary range of time. Fuzzy times such as "yesterday" and "2 hours ago"—with quotes—are also allowed.
-u [unit name] The -u option allows you to select specific units to examine. You can use a unit name or a pattern for matching. This option can be used multiple times to match multiple units or patterns. 
-U , --until [timestamp] These show all journal entries until (prior to) the specified time. They can be used with --since  to display an arbitrary range of time. Fuzzy times such as "yesterday" and "2 hours ago"—with quotes—are also allowed.

I'll explore some of these entries below. More options can be found in the journalctl man page.

Journal files

If you have not already, be sure to list the files in the journal directory on your host. Remember that the name of the directory containing the journal files is a long, random number. This directory contains multiple active and archived journal files, including some for users:

[root@david ~]# cd /var/log/journal/ad8f29ed15044f8ba0458c846300c2a4/
[root@david ad8f29ed15044f8ba0458c846300c2a4]# ll
total 352308
-rw-r-----+ 1 root systemd-journal  33554432 May 28 13:07 system@0c91aaef57c441859ea5e421edff6528-0000000000000001-0005a6703120d448.journal
-rw-r-----+ 1 root systemd-journal 109051904 Jun 23 21:24 system@0c91aaef57c441859ea5e421edff6528-0000000000008238-0005a6b85e4e03c6.journal
-rw-r-----+ 1 root systemd-journal 100663296 Jul 21 18:39 system@0c91aaef57c441859ea5e421edff6528-0000000000021f3e-0005a8ca55efa66a.journal
-rw-r-----+ 1 root systemd-journal  41943040 Jul 30 09:34 system.journal
-rw-r-----+ 1 root systemd-journal   8388608 May 28 13:07 user-1000@037bcc7935234a5ea243b3af304fd08a-0000000000000c45-0005a6705ac48a3c.journal
-rw-r-----+ 1 root systemd-journal  16777216 Jun 23 21:24 user-1000@bc90cea5294447fba2c867dfe40530db-0000000000008266-0005a6b85e910761.journal
-rw-r-----+ 1 root systemd-journal  41943040 Jul 21 16:08 user-1000@bc90cea5294447fba2c867dfe40530db-0000000000021f4b-0005a8ca68c83ab7.journal
-rw-r-----+ 1 root systemd-journal   8388608 Jul 30 09:34 user-1000.journal
[root@david ad8f29ed15044f8ba0458c846300c2a4]#

You can see the user files in this listing for the user ID (UID) 1000, which is my Linux account. The --files option allows me to see the content of specified files, including the user files:

[root@david ad8f29ed15044f8ba0458c846300c2a4]# journalctl --file user-1000.journal

Jul 29 14:13:32 david.both.org tumblerd[145509]:Registered thumbnailer /usr/bin/gdk-pixbuf-thumbnailer -s %s %u %o
Jul 29 14:13:32 david.both.org Thunar[2788]:ThunarThumbnailer:got 0 handle (Queue)
Jul 29 14:13:32 david.both.org Thunar[2788]:ThunarThumbnailer:got 0 handle (Error or Ready)
Jul 29 14:13:32 david.both.org Thunar[2788]:ThunarThumbnailer:got 0 handle (Finished)
Jul 29 14:15:33 david.both.org tumblerd[145552]:error:Broken zip file structure
Jul 29 14:20:34 david.both.org systemd[2466]:dbus-:[email protected]:Succeeded.
Jul 29 14:34:17 david.both.org systemd[2466]:Starting Cleanup of User's Temporary Files and Directories...
Jul 29 14:34:17 david.both.org systemd[2466]:systemd-tmpfiles-clean.service:Succeeded.
Jul 29 14:34:17 david.both.org systemd[2466]:Finished Cleanup of User's Temporary Files and Directories.
Jul 29 14:48:26 david.both.org systemd[2466]:Started dbus-:[email protected].
Jul 29 14:48:26 david.both.org tumblerd[145875]:Registered thumbnailer gsf-office-thumbnailer -i %i -o %o -s %s

This output shows, among other things, temporary file cleanup for the UID1000 user. Data relating to individual users may be helpful in locating the root cause of problems originating in user space. I found a number of interesting entries in this output. Try it on your host and see what you find.

Adding journal entries

It can be useful to add your own entries to the journal. This is accomplished with the systemd-cat program that allows piping the STDOUT of a command or program to the journal. This command can be used as part of a pipeline on the command line or in a script:

[root@testvm1 ~]# echo "Hello world" | systemd-cat -p info -t myprog
[root@testvm1 ~]# journalctl -n 10
Jul 27 09:01:01 testvm1.both.org CROND[976442]:(root) CMD (run-parts /etc/cron.hourly)
Jul 27 09:01:01 testvm1.both.org run-parts[976445]:(/etc/cron.hourly) starting 0anacron
Jul 27 09:01:01 testvm1.both.org run-parts[976451]:(/etc/cron.hourly) finished 0anacron
Jul 27 09:07:53 testvm1.both.org unknown[976501]:Hello world
Jul 27 09:10:47 testvm1.both.org systemd[1]:Starting system activity accounting tool...
Jul 27 09:10:47 testvm1.both.org systemd[1]:sysstat-collect.service:Succeeded.
Jul 27 09:10:47 testvm1.both.org systemd[1]:Finished system activity accounting tool.
Jul 27 09:10:47 testvm1.both.org audit[1]:SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/syst>
Jul 27 09:10:47 testvm1.both.org audit[1]:SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=sysstat-collect comm="systemd" exe="/usr/lib/syste>
Jul 27 09:17:10 testvm1.both.org myprog[976516]:Hello world
[root@testvm1 ~]#

The -p option specifies a priority, emerg, alert, crit, err, warning, notice, info, debug, or a value between 0 and 7 that represents each of those named levels. These priority values are the same as those defined by syslog(3) . The default is info. The -t option is an identifier, which can be any arbitrary short string, such as a program or script name. This string can be used for searches by the journalctl comando:

[root@testvm1 ~]# journalctl -t myprog
-- Logs begin at Mon 2020-06-08 07:47:20 EDT, end at Mon 2020-07-27 09:21:57 EDT. --
Jul 27 09:17:10 testvm1.both.org myprog[976516]:Hello world
[root@testvm1 ~]#

Journal management

I use the --disk-usage option to check on journal sizes, along with other commands relating to disk usage, to ensure that my /var filesystem is not filling up:

[root@testvm1 ~]# journalctl --disk-usage 
Archived and active journals take up 136.0M in the file system.
[root@testvm1 ~]#

The disk usage for the journals on the testvm1 host is about 136MB. The result on my primary workstation is 328MB, and the host I use for my firewall and router uses 2.8GB for the journals. Journal sizes depend greatly on the host's use and daily run time. My physical hosts all run 24x7.

The /etc/systemd/journald.conf file can be used to configure the journal file sizes, rotation, and retention times to meet any needs not met by the default settings. You can also configure the journal storage location—you can specify a directory on the storage device or whether to store everything in RAM, which is volatile storage. If the journals are stored in RAM, they will not be persistent between boots.

The default time unit in the journald.conf file is seconds, but it can be overridden using the suffixes year , month , week , day , h , or m .

Suppose you want to limit the total amount of storage space allocated to journal files to 1GB, store all journal entries in persistent storage, keep a maximum of 10 files, and delete any journal archive files that are more than a month old. You can configure this in /etc/systemd/journald.conf using:

SystemMaxUse=1G
Storage=persistent
SystemMaxFiles=10
MaxRetentionSec=1month

By default, the SystemMaxUse is 10% of available disk space. The default settings have been fine for the systems I work with, and I have not needed to change any of them. The journald.conf man page states that the time-based settings for specifying how long to store journal entries in a single file or to retain older files are normally not necessary. This is because file number and size configurations usually force rotation and deletion of old files before any time settings might be needed.

The SystemKeepFree option ensures a specific amount of space is kept free for other data. Many databases and application programs use the /var filesystem to store data, so ensuring enough available storage space may be critical in systems with smaller hard drives and minimum space allocated to /var .

If you make changes to this configuration, be sure to monitor the results carefully for an appropriate period of time to ensure they are performing as expected.

Journal file rotation

The journal files are typically rotated automatically based upon the configuration in the /etc/systemd/journald.conf expediente. Files are rotated whenever one of the specified conditions is met. So if, for example, the space allocated to journal files is exceeded, the oldest file(s) is deleted, the active file is made into an archive, and a new active file is created.

Journal files can also be rotated manually. I suggest using the --flush option to ensure current data is moved to persistent storage before you run the command:

[root@testvm1 ~]# journalctl --rotate 

There is another way to purge old journal files without performing a file rotation. The vacuum-size= , vacuum-files= , and vacuum-time= commands can be used to delete old archive files down to a specified total size, number of files, or prior time. The option values consider only the archive files and not the active ones, so the resulting reduction in total file size might be somewhat less than expected.

The following command purges old archive files so that only ones that are less than one month old are left. You can use the s , m , h , days , months , weeks , and years suffixes:

[root@testvm1 ~]# journalctl --vacuum-time=1month  

This command deletes all archive files except for the four most recent ones. If there are fewer than four archive files, nothing will happen, and the original number of files remains:

[root@testvm1 ~]# journalctl --vacuum-files=4 

This last vacuum command deletes archive files until 200MB or less of archived files are left:

[root@testvm1 ~]# journalctl --vacuum-size=200M 

Only complete files are deleted. The vacuum commands do not truncate archive files to meet the specification. They also work only on archive files, not active ones.

Pensamientos finales

This article looked at using the journalctl command to extract various types of data from the systemd journal in different formats. It also explored managing journal files and how to add entries to the log from commands and scripts.

The systemd journal system provides a significant amount of metadata and context for entries compared to the old syslogd program. This additional data and the context available from the other journal entries around the time of an incident can help the sysadmin locate and resolve problems much faster than having to search multiple syslog files.

In my opinion, the journalctl command meets the Unix philosophy that programs should do one thing and do it well. The only thing journalctl does is extract data from the journal and provide many options for selecting and formatting that data. At about 85K, it is not very big. Of course, that does not include shared libraries, but those are, by definition, shared with other programs.

You should now have enough information to use the systemd journal more effectively. If you would like to know more than what I covered here, look in the man pages for journalctl and systemd-cat .

Resources

There is a great deal of information about systemd available on the internet, but much is terse, obtuse, or even misleading. In addition to the resources mentioned in this article, the following webpages offer more detailed and reliable information about systemd startup. This list has grown since I started this series of articles to reflect the research I have done.

  • DigitalOcean has a very good article about journalctl and how to view and manipulate systemd logs.
  • The Fedora Project has a good, practical guide to systemd. It has pretty much everything you need to know in order to configure, manage, and maintain a Fedora computer using systemd.
  • The Fedora Project also has a good cheat sheet that cross-references the old SystemV commands to comparable systemd ones.
  • Red Hat documentation contains a good description of the Unit file structure as well as other important information.
  • For detailed technical information about systemd and the reasons for creating it, check out Freedesktop.org's description of systemd.
  • Linux.com's "More systemd fun" offers more advanced systemd information and tips.

There is also a series of deeply technical articles for Linux sysadmins by Lennart Poettering, the designer and primary developer of systemd. These articles were written between April 2010 and September 2011, but they are just as relevant now as they were then. Much of everything else good that has been written about systemd and its ecosystem is based on these papers.

  • Rethinking PID 1
  • systemd for Administrators, Part I
  • systemd for Administrators, Part II
  • systemd for Administrators, Part III
  • systemd for Administrators, Part IV
  • systemd for Administrators, Part V
  • systemd for Administrators, Part VI
  • systemd for Administrators, Part VII
  • systemd for Administrators, Part VIII
  • systemd for Administrators, Part IX
  • systemd for Administrators, Part X
  • systemd for Administrators, Part XI

Linux
  1. Mensajes de error "Cancelar comando emitido nexus" en el archivo /var/log/messages

  2. Observación de registros usando la cola o menos

  3. Eliminar archivos de registro usando el trabajo cron

  4. usando temporizadores systemd en lugar de cron

  5. Los registros del sistema están vacíos (/var/log/messages; /var/log/secure; etc.)

Uso de Telnet para solucionar problemas de su sistema de correo

Uso de las funciones de systemd para proteger los servicios

Configuración de registro remoto mediante rsyslog en CentOS/RHEL

Uso de vmstat para solucionar problemas de rendimiento en Linux

RabbitMQ:obtenga mensajes de una cola usando curl

redirigir los registros del servicio systemd al archivo

    Option Description
    -f , --follow This journalctl option is similar to using the tail -f dominio. It shows the most recent entries in the journal that match whatever other options have been specified and also displays new entries as they occur. This can be useful when watching for events and when testing changes.
    -e , --pager-end The -e option displays the end of the data stream instead of the beginning. This does not reverse the order of the data stream, rather it causes the pager to jump to the end.
    --file [journal filename] This names a specific journal file in /var/log/journal/ .
    -r , --reverse This option reverses the order of the journal entries in the pager so that the newest are at the top rather than the bottom.
    -n , --lines=[X] This shows the most recent X number of lines from the journal.
    --utc This displays times in UTC rather than local time.
    -g , --grep=[REGEX] I like the -g option because it enables me to search for specific patterns in the journal data stream. This is just like piping a text data stream through the grep dominio. This option uses Perl-compatible regular expressions.
    --disk-usage This option displays the amount of disk storage used by the current and archived journals. It might not be as much as you think.
    --flush Journal data stored in the virtual filesystem /run/log/journal/ , which is volatile storage, is written to /var/log/journal/ which is persistent storage. This option ensures that all data is flushed to /run/log/journal/ at the time it returns.
    --sync This writes all unwritten journal entries (still in RAM but not in /run/log/journal ) to the persistent filesystem. All journal entries known to the journaling system at the time the command is entered are moved to persistent storage.
    --vacuum-size= --vacuum-time= --vacuum-files= These can be used singly or in combination to remove the oldest archived journal files until the specified condition is met. These options only consider archived files, and not active files, so the result might not be exactly what was specified.