Verwenden von systemd-Journalen zur Behebung vorübergehender Probleme

„Ich habe eigentlich keine besonders starke Meinung zu systemd selbst. Ich hatte Probleme mit einigen der Core-Entwickler, die meiner Meinung nach viel zu unbekümmert in Bezug auf Fehler und Kompatibilität sind, und ich denke, dass einige der Designdetails verrückt sind (I mag zum Beispiel die Binärlogs nicht), aber das sind Details, keine großen Probleme." – Linus Torvalds, zitiert in ZDNets „Linus Torvalds and other on Linux’s systemd“ im Jahr 2014

Die systemd-Journaldateien werden in einem oder mehreren Unterverzeichnissen von /var/log/journal gespeichert . Melden Sie sich bei einem Testsystem an, auf dem Sie Root-Zugriff haben, und erstellen Sie /var/log/journal das aktuelle Arbeitsverzeichnis (PWD). Listen Sie dort die Unterverzeichnisse auf, wählen Sie eines aus und machen Sie es zum PWD. Sie können sich diese Dateien auf verschiedene Weise ansehen. Ich habe mit dem stat begonnen Befehl (beachten Sie, dass sich die Namen der Journaldateien auf Ihrem Host von meinen unterscheiden):

 [root @ testvm1 3bccd1140fca488187f8a1439c832f07] # stat system@7ed846aadf1743139083681ec4042037-0000000000000001-0005a99c0280fd5f.journal 
 Datei:system@7ed846aadf1743139083681ec4042037-0000000000000001-0005a99c0280fd5f.journal 
 Größe:8388608 Blöcke:16392 IO Block:4096 regelmäßige file
Device:fd04h/64772d    Inode:524384      Links:1
Access:(0640/-rw-r-----)  UId:(    0/    root)   Gid:(  190/systemd-journal )
Zugriff:2020-07-13 08:30:05.764291231 -0400
Änderung:2020-07-04 07:33:52.916001110 -0400
Änderung:2020-07-04 07:33:52.916001110 -0400
 Geburt:-
[root@testvm1 3bccd1140fca488187f8a1439c832f07]#

Die Journaldatei wird als "normale" Datei identifiziert, was nicht besonders hilfreich ist. Die Datei Der Befehl identifiziert es als eine "Journal" -Datei, aber das wissen Sie bereits. Schauen Sie in die Datei mit dem dd Befehl. Der folgende Befehl sendet den Ausgabedatenstrom an STDOUT; Vielleicht möchten Sie es durch less leiten Pager:

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

9�P1�8��9_SOURCE_MONOTONIC_TIMESTAMP=191726���/��P����9MESSAGE=Inode-Cache-Hash-Tabelleneinträge:1048576 (Reihenfolge:11, 8388608 Bytes , linear)�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=Speicher:12598028K/12963384K verfügbar (14339K Kernelcode, 2406K rwdata, 8164K Rodata, 2468K init, 5072K b
ss, 365356K reserviert, 0K cma-reserviert)�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 aufgerufen von __kmem_cache_create+0x3e/0x610 mit
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, CPUs=4, Knoten=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�9MESSAGE =Isolierung Kernel-/Benutzerseitentabellen:aktiviert�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:Zuordnung von 41361 Einträgen auf 162 Seiten�n ����(n�O���@Y�

Auch dieser kleine Teil des Datenstroms aus dem dd Befehl zeigt eine interessante Mischung aus ASCII-Text und binären Daten. Ein weiteres nützliches Werkzeug sind die Strings Befehl, der einfach alle in einer Datei enthaltenen ASCII-Textzeichenfolgen anzeigt und die Binärdaten ignoriert:

 [root @ testvm1 3bccd1140fca488187f8a1439c832f07] # Saiten System@7ED846AADF17431390836811743137-00000000000000013-0005A99c0280FD5F.Journal 
 
 
 Nachricht =Linux Version 5.7.6-201.fc32.x86_64 ([email protected] .fedoraproject.org) (gcc Version 10.1.1 20200507 (Red Hat 10.1.1-1) (GC
C), GNU ld Version 2.34-3.fc32) #1 SMP Mo 29. Juni 15:15:52 UTC 2020
MESSAGE
_BOOT_ID=6e944f99ebd9405984090f829a927fa4
_BOOT_ID
_MACHINE_ID=3bccd1140fca488187f8a1439c832f07
_MACHINE_ID
_HOSTNAME=testvm1
_HOSTNAME=testvm1>PRIORITY=6
MESSAGE=Befehlszeile: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:XSAVE wird unterstützt Feature 0x001:'x87 Floating Point Registers'
MESSAGE=x86/fpu:Unterstützung von XSAVE Feature 0x002:'SSE Registers'
MESSAGE=x86/fpu:Unterstützung von XSAVE Feature 0x00 4:„AVX-Register“
Z_g3;
MESSAGE=x86/fpu:xstate_offset[2]: 576, xstate_sizes[2]: 256
Z_g3;
MESSAGE=x86/fpu :Aktivierte xstate-Funktionen 0x7, Kontextgröße ist 832 Bytes, unter Verwendung des 'Standard'-Formats.
MESSAGE=BIOS-bereitgestellte physische RAM-Zuordnung:
`k2X
MESSAGE=BIOS-e820:[mem 0x0000000000000000 -0x000000000009FBFF] Nutzbare 
 Nachricht =BIOS-E820:[MEM 0x000000000009FC00-0x000000000009FFFF] Reserviert 
 Nachricht =BIOS-E820:[MEM 0x00000000000F0000-0x00000000000FFFF] Reserviert 
 Pylm 
 Nachricht =BIOS -E820:[MEM 0x000000000000100000-0x000000000000100000-0X00000000DFFFFFFF] Nutzbare 
 Nachricht =BIOS-E820:[MEM 0x00000000DFFFFFFFFFFFFFFFFFFFF] ACPI-Daten 
 Nachricht =BIOS-E820:[MEM 0x00000000FEC00000-0X00000000FEC00FFF] Reservierte 
 Nachricht =BIOS-E820:[MEM 0x00000000FEE00000-0X00000000FEE00FFF] Reserviert 
 Nachricht =BIOS-E820:[MEM 0x00000000FFFC0000-0x00000000FFFFFFFF] Reserviert 
 Nachricht =BIOS-E820:[MEM 0x0000000100000000-0x00000003373FFFFF] Nutzbare 
 

Diese Daten können von Menschen interpretiert werden, und dieses spezielle Segment sieht dem Ausgabedatenstrom von dmesg sehr ähnlich Befehl. Ich überlasse es Ihnen, weiter zu forschen, aber meine Schlussfolgerung ist, dass die Journaldateien eindeutig eine Mischung aus Binär- und ASCII-Text sind. Diese Mischung macht es umständlich, herkömmliche textbasierte Linux-Tools zum Extrahieren nutzbarer Daten zu verwenden. Aber es gibt einen besseren Weg, der viele Möglichkeiten zum Extrahieren und Anzeigen von Journaldaten bietet.

Über journalctl

Das journalctl Der Befehl wurde entwickelt, um nutzbare Informationen aus den systemd-Journalen zu extrahieren, indem leistungsstarke und flexible Kriterien zur Identifizierung der gewünschten Daten verwendet werden. Frühere Artikel dieser Reihe haben journalctl beschrieben , und es gibt noch mehr zu wissen.

Ich werde zuerst ein wenig wiederholen und mit einigen Grundlagen beginnen, falls Sie die vorherigen Artikel nicht gelesen haben oder nur eine Auffrischung benötigen.

Sie können das journalctl verwenden Befehl ohne Optionen oder Argumente, um das systemd-Journal anzuzeigen, das alle Journal- und Protokollinformationen enthält:

[root@testvm1 ~]# journalctl
-- Protokolle beginnen am Mo. 2020-06-08 07:47:20 EDT und enden am Do. 2020-07-16 10:30:43 EDT. --
08. Juni 07:47:20 Kernel testvm1.both.org:Linux-Version 5.6.6-300.fc32.x86_64 ([email protected]) (gcc-Version 10.0>
 8. Juni 07:47:20 Kernel testvm1.both.org:Befehlszeile:BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.6.6-300.fc32.x86_64 root=/dev/mapper/VG01-root ro>
Jun 08 07:47:20 testvm1.both.org Kernel:x86/fpu:Unterstützung von XSAVE-Funktion 0x001:'x87 Floating Point Registers'
Jun 08 07:47:20 testvm1.both.org Kernel:x86/fpu:Unterstützung von XSAVE-Funktion 0x002:'SSE registers'
Jun 08 07:47:20 testvm1.both.org Kernel:x86/fpu:Unterstützung von XSAVE-Funktion 0x004:'AVX registers'
Jun 08 07:47:20 Kernel von testvm1.both.org:x86/fpu:xstate_offset[2]: 576, xstate_sizes[2]: 256
08. Juni 07:47:20 Kernel von testvm1.both.org:x86/fpu :Aktivierte xstate-Funktionen 0x7, Kontextgröße ist 832 Bytes, unter Verwendung des „Standard“-Formats.
08.06 :47:20 testvm1.both.org Kernel:BIOS-e820:[mem 0x00 00000000000000-0x000000000009fbff] verwendbar

Jul 16 09:51:00 testvm1.both.org NetworkManager[760]:  [1594907460.1765] dhcp4 (enp0s3):option require_routers    => '1 '
16. Juli 09:51:00 testvm1.both.org NetworkManager[760]:  [1594907460.1765] dhcp4 (enp0s3):option require_static_routes => '1'
16. Juli 09:51:00 testvm1.both.org NetworkManager[760]:  [1594907460.1765] dhcp4 (enp0s3):Option requested_subnet_mask => '1'
16. Juli 09:51:00 testvm1.both.org NetworkManager[760]:  [1594907460.1765] dhcp4 (enp0s3):option require_time_offset => '1'
16. Juli 09:51:00 testvm1.both.org NetworkManager[760]:  [1594907460.1766] dhcp4 (enp0s3):Option angefordert_wpad       => '1'
Jul 16 09:51:00 testvm1.both.org NetworkManager[760]:  [1594907460.1766] dhcp4 (enp0s3):option routers              => '192.168.0.2>
16. Juli 09:51:00 testvm1.both.org NetworkManager[760]: [1594907460.1766] dhcp4 (enp0s3):option subnet_ mask          => '255.255.255>
Jul 16 09:51:00 testvm1.both.org NetworkManager[760]:  [1594907460.1766] dhcp4 (enp0s3):Status geändert erweitert -> erweitert
 16. Juli 09:51:00 testvm1.both.org systemd[1]:Network Manager Script Dispatcher Service wird gestartet...
16. Juli 09:51:00 testvm1.both.org systemd[1]:Network Manager gestartet Script Dispatcher Service.
16. Juli 09:51:00 testvm1.both.org audit[1]:SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=NetworkManager-dispatcher com>
16. Juli 09:51:10 testvm1.both.org systemd[1]:NetworkManager-dispatcher.service:Erfolgreich.
16. Juli 09:51:10 testvm1.both.org audit[1]:SERVICE_STOP pid =1 uid=0 auid=4294967295 ses=4294967295 msg='unit=NetworkManager-dispatcher comm>
Jul 16 09:59:13 testvm1.both.org systemd[1]:Starting dnf makecache...
16. Juli 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. Juli 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. Juli 09:59:13 testvm1.both.org systemd[1]:dnf-makecache.service:Erfolgreich.
16. Juli 09:59:13 testvm1.both.org systemd[1]:dnf makecache beendet.
16. Juli 09 :59:14 testvm1.both.org dnf[378549]:Metadaten-Cache kürzlich aktualisiert.
16. Juli 10:00:42 testvm1.both.org systemd[1]:Systemaktivitäts-Abrechnungstool wird gestartet...
16. Juli 10:00:42 testvm1.both.org systemd[1]:sysstat-collect.service:Erfolgreich.
16. Juli 10:00:42 testvm1.both.org audit[1]:SERVICE_START pid =1 uid=0 auid=4294967295 ses=4294967295 msg='unit=sysstat-collect comm="systemd>
Jul 16 10:00:42 testvm1.both.org systemd[1]:Fertiges Tool zur Erfassung der Systemaktivität .
16. Juli 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. Juli 10:01:01 testvm1.both.org CROND[378562]:(root) CMD (run-parts /etc/cron.hourly)
16. Juli 10:01:01 testvm1.both.org run-parts[378565]:(/etc/cron.hourly) ab 0anacron
16. Juli 10:01:01 testvm1.both.org run-parts[378571]:(/etc/cron.hourly) beendet 0anacron

Sie können dieselben Daten auch explizit im dmesg anzeigen Befehl präsentiert. Öffnen Sie zwei Terminalsitzungen nebeneinander und geben Sie den dmesg aus Befehl in einem und dem folgenden Befehl in dem anderen:

[root@testvm1 ~]# journalctl --dmesg 

Der einzige Unterschied, den Sie sehen sollten, ist das Zeitformat. Die dmesg Der Befehl hat ein monotones Format, das die Anzahl der Sekunden seit dem Systemstart anzeigt. Das journalctl Die Ausgabe erfolgt in einem Datums- und Zeitformat. Die Option short-monotonic zeigt die Zeit seit dem Booten an:

[root@testvm1 ~]# journalctl --dmesg -o short-monotonic
-- Protokolle beginnen am Mo. 2020-06-08 07:47:20 EDT und enden am Mo. 2020-07-20 13 :01:01 EDT. --
[    0.000000] Kernel testvm1.both.org:Linux-Version 5.7.6-201.fc32.x86_64 ([email protected]) (gcc-Version 10.1.>
[    0.000000 ] Kernel testvm1.both.org:Befehlszeile:BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.7.6-201.fc32.x86_64 root=/dev/mapper/VG01-root ro r>
[    0.000000] testvm1.both.org Kernel:x86/fpu:Unterstützung von XSAVE-Funktion 0x001:'x87 Floating Point Registers'
[    0.000000] testvm1.both.org Kernel:x86/fpu:Unterstützung von XSAVE-Funktion 0x002:'SSE Registers'
[    0.000000] testvm1.both.org Kernel:x86/fpu:Unterstützung von XSAVE-Funktion 0x004:'AVX registers'
[    0.000000] testvm1.both.org Kernel:x86/fpu:xstate_offset[2]: 576 , xstate_sizes[2]: 256
[    0.000000] testvm1.both.org Kernel:x86/fpu:Aktivierte xstate-Funktionen 0x7, Kontextgröße ist 832 Byte, unter Verwendung des „Standard“-Formats.


[    0.000002] testvm1.both.org Kernel:Clocksource:kvm-clock:Maske:0xffffffffffffffff max_cycles:0x1cd42e4dffb, max_idle_ns:881 5905914>
[    0.000005] testvm1.both.org Kernel:tsc:2807.988 MHz Prozessor erkannt
[    0.001157] testvm1.both.org Kernel:e820:Update [mem 0x00000000-0x00000fff] verwendbar ==> reserviert 
[    0.001159] testvm1.both.org Kernel:e820:entfernt [mem 0x000a0000-0x000fffff] verwendbar
[    0.001162] testvm1.both.org Kernel:last_pfn =0x24ec00 max_arch_pfn =0x40000000 0[    0.001173] testvm1.both.org-Kernel:MTRR-Variablenbereiche deaktiviert:
[    0.001173] testvm1.both.org-Kernel:deaktiviert
[    0.001174] testvm1.both.org Kernel:x86/PAT:MTRRs deaktiviert, PAT-Initialisierung wird ebenfalls übersprungen.
[    0.001176] testvm1.both.org Kernel:CPU-MTRRs alle leer - virtualisiertes System.
[ 0.001179] Kernel testvm1.both.org:x86/PAT:Konfiguration [0-7]:WB  WT  UC- UC  WB  WT  UC- UC  
[   0.001182] Kernel testvm1.both.org:last_pfn =0xdfff0 max_arch_pfn =0x400000000 
[    0.001238] Test vm1.both.org Kernel:gefundene SMP MP-Tabelle unter [mem 0x0009fff0-0x0009ffff]
[    0.081068] testvm1.both.org Kernel:RAMDISK:[mem 0x34194000-0x360c1fff]
[    0.081088] testvm1. both.org-Kernel:ACPI:Überprüfung der frühen Tabellenprüfsumme deaktiviert


[   34.037575] testvm1.both.org-Kernel:16:43:32.734466 main     6.1.10_Fedora r138449 gestartet. Verbose level =0
[   34.042209] testvm1.both.org Kernel:16:43:32.739032 main     vbglR3GuestCtrlDetectPeekGetCancelSupport:Unterstützt (#1)
[   55.746944] testvm1.both.org Kernel:e1000:enp0s3 NIC Link ist Up 1000 Mbps Full Duplex, Flow Control:RX
[   55.747738] testvm1.both.org Kernel:IPv6:ADDRCONF(NETDEV_CHANGE):enp0s3:Verbindung wird bereit


Zeilen 624 -681/681 (ENDE)

Das journalctl Der Befehl hat viele Optionen, einschließlich -o (Ausgabe)-Option mit mehreren Unteroptionen, mit denen Sie ein Zeit- und Datumsformat auswählen können, das unterschiedliche Anforderungen erfüllt. Ich habe die meisten von ihnen unten aufgelistet, zusammen mit einer kurzen Beschreibung, die ich aus dem journalctl erweitert oder modifiziert habe Manpage. Beachten Sie, dass der Hauptunterschied zwischen den meisten davon das Format von Datum und Uhrzeit ist und die anderen Informationen gleich bleiben.

journalctl Zeit- und Datumsformate

• kurz: Dies ist das Standardformat und generiert eine Ausgabe, die der Formatierung klassischer Syslog-Dateien am nächsten kommt und eine Zeile pro Journaleintrag anzeigt. Diese Option zeigt Journal-Metadaten an, einschließlich der monotonen Zeit seit dem Booten, dem vollständig qualifizierten Hostnamen und dem Unit-Namen wie Kernel, DHCP usw.
  

  Jul 20 08:43:01 testvm1.both .org-Kernel:Inode-Cache-Hash-Tabelleneinträge:1048576 (Reihenfolge:11, 8388608 Bytes, linear) 

• kurz-voll:  Dieses Format ist dem Standardformat sehr ähnlich, zeigt jedoch Zeitstempel im Format --since= an und --until= Optionen akzeptieren. Im Gegensatz zu den Zeitstempelinformationen, die im kurzen Ausgabemodus angezeigt werden, enthält dieser Modus Informationen zu Wochentag, Jahr und Zeitzone in der Ausgabe und ist gebietsschemaunabhängig.
  

  Mo 2020-06-08 07:47:20 EDT testvm1.both.org Kernel:x86/fpu:Unterstützung der XSAVE-Funktion 0x004:'AVX registers' 

• Kurz-iso: Das Short-ISO-Format ist dem Standardformat sehr ähnlich, zeigt jedoch ISO 8601-Wallclock-Zeitstempel an.
  

  2020-06-08T07:47:20-0400 testvm1.both.org kernel:kvm-clock :Verwenden von MSRS 4b564d01 und 4b564d00 

• kurz-iso-präzise:   Dieses Format ist das gleiche wie short-iso, enthält aber volle Mikrosekunden-Präzision.
  

  2020-06-08T07:47:20.223738-0400 testvm1.both.org kernel:Booting paravirtualized kernel on KVM 

• kurz-monoton:   Dem Standard sehr ähnlich, zeigt aber monotone Zeitstempel statt Wallclock-Zeitstempel.
  

  [    2.091107] testvm1.both.org Kernel:ata1.00:ATA-6:VBOX HARDDISK, 1.0, max UDMA/ 133 

• kurz präzise:  Auch dieses Format ähnelt dem Standardformat, zeigt aber klassische Syslog-Zeitstempel mit voller Mikrosekunden-Präzision. 0x000000000009ffff] reserviert
• kurz Unix:  Wie die Standardeinstellung, zeigt aber die seit dem 1. Januar 1970 verstrichenen Sekunden UTC anstelle der Zeitstempel der Wanduhr ("Unix-Zeit"). Die Zeit wird mit Mikrosekundengenauigkeit angezeigt.
  

  1591616840.232165 testvm1.both.org Kernel:tcp_listen_portaddr_hash Hash-Tabelleneinträge:8192 

• Katze: Erzeugt eine sehr knappe Ausgabe, die nur die Nachricht jedes Journaleintrags ohne Metadaten zeigt, nicht einmal einen Zeitstempel.
  

  ohci-pci 0000:00:06.0:irq 22, io mem 0xf0804000 

• ausführlich: Dieses Format zeigt die vollständige Datenstruktur für alle Eintragselemente mit allen Feldern. Dies ist die Formatoption, die sich am meisten von allen anderen unterscheidet.
  

  Mon 2020-06-08 07:47:20.222969 EDT [s=d52ddc9f3e8f434b9b9411be2ea50b1e;i=1;b=dcb6dcc0658e4a8d8c781c21a2c6360d;m=242 t=5a7912c6148f9;x=8f>
      _SOURCE_MONOTONIC_TIMESTAMP=0
      _TRANSPORT=kernel
      PRIORITY=5
      SYSLOG_FACILITY=0
      SYSLOG_IDENTIFIER=kernel
      MESSAGE=Linux Version 5.6.6-300.fc32.x86_64 ([email protected]) (gcc-Version 10.0.1 20200328 (Red Hat 10.0.1-0>
      _BOOT_ID=dcb6dcc0658e4a8d8c781c21a2c6360d
   3bccd1140fca488187f8a1439c832f07
      _HOSTNAME=testvm1.both.org

Andere Auswahlmöglichkeiten, verfügbar mit -o Option erlauben den Export der Daten in verschiedenen Formaten wie Binär oder JSON. Ich finde auch das -x Option aufleuchtend, weil sie zusätzliche erklärende Meldungen für einige Journaleinträge anzeigen kann. Wenn Sie diese Option ausprobieren, beachten Sie, dass sie den Ausgabedatenstrom erheblich erhöhen kann. Beispielsweise die Zusatzinformationen für einen Eintrag wie:

[    4.503737] testvm1.both.org systemd[1]:Dateisystemprüfung auf /dev/mapper/VG01-root starten...
[    4.691555] testvm1.both.org systemd-fsck[548] :root:sauber, 1813/327680 Dateien, 48555/1310720 Blöcke
[    4.933065] testvm1.both.org systemd[1]:File System Check auf /dev/mapper/VG01-root abgeschlossen.

erweitert sich zu diesem:

[    4.503737] testvm1.both.org systemd[1]:Starten der Dateisystemprüfung auf /dev/mapper/VG01-root...
-- Betreff:Ein Startjob für Unit systemd-fsck-root .service hat mit der Ausführung begonnen
-- Definiert von:systemd
-- Support:https://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Ein Startjob für die Unit systemd-fsck-root.service hat mit der Ausführung begonnen.
-- 
-- Die Job-ID ist 36.
[    4.691555] testvm1.both.org systemd -fsck[548]:root:clean, 1813/327680 files, 48555/1310720 blocks
[    4.933065] testvm1.both.org systemd[1]:Dateisystemprüfung auf /dev/mapper/VG01-root abgeschlossen. 
-- Betreff:Ein Startjob für die Unit systemd-fsck-root.service wurde erfolgreich beendet
-- Defined-By:systemd
-- Support:https://lists.freedesktop. org/mailman/listinfo/systemd-devel
-- 
-- Ein Startjob für die Einheit systemd-fsck-root.service wurde erfolgreich beendet.
-- 
-- Die Job-ID ist 36

Hier gibt es einige neue Informationen, aber ich denke, der Hauptvorteil besteht darin, dass die Informationen kontextualisiert sind, um die ursprünglichen knappen Botschaften bis zu einem gewissen Grad zu verdeutlichen.

Eingrenzen der Suche

Meistens ist es nicht notwendig oder gar wünschenswert, alle Journaleinträge aufzulisten und manuell zu durchsuchen. Manchmal suche ich nach Einträgen, die sich auf einen bestimmten Dienst beziehen, und manchmal suche ich nach Einträgen, die zu bestimmten Zeiten stattgefunden haben. Das journalctl Der Befehl bietet leistungsstarke Optionen, mit denen Sie nur die Daten sehen können, an denen Sie interessiert sind.

Beginnen Sie mit --list-boots Option, die alle Stiefel während des Zeitraums auflistet, in dem Journaleinträge vorhanden sind. Beachten Sie, dass die journalctl.conf file kann angeben, dass Journaleinträge verworfen werden, nachdem sie ein bestimmtes Alter erreicht haben oder nachdem der von den Journalen belegte Speicherplatz auf dem Speichergerät (HDD/SSD) eine bestimmte maximale Menge erreicht hat:

[root@testvm1 ~]# journalctl --list-boots 
-10 dcb6dcc0658e4a8d8c781c21a2c6360d Mo 2020-06-08 07:47:20 EDT—Mo 2020-06-08 07:53:05 EDT
 -9 7d61951a85f445c5946774aaae8bc2a4 Fr 2020-07-03 15:50:06 EDT—Fr 2020-07-03 18:21:23 EDT
 -8 1b3a847577e544b4a2679fe576b62206 Fr 18-02306 Fr 27:0230 Fr 2020-07-03 22:10:54 EDT
 -7 5fef01a3568743af99118107ca6f61ae Fr 2020-07-03 22:18:41 EDT—Sa 2020-07-04 06:50:19 EDT
 -6 6e944f99ebd9405984090f829a927fa4 Sa 2020-07-04 07:33:25 EDT—Sa 2020-07-04 07:58:59 EDT
 -5 ec8b0c81ca4744b1bad071bdef432959 Sa 2020-07-04 07.07.2020:12.07 -04 09:12:47 EDT
 -4 cb173ec716824e21b87ccf6cb43a9a99 Sa 2020-07-04 10:19:53 EDT—Sa 2020-07-04 11:31:03 EDT
 -3 4fe354a893194409823 Sa20a6d603aa9d603aa9d603aa9d60 07-04 07:59:58 EDT—So 2020-07-05 09:39:30 EDT
 -2 06fb81f1b29e4f68af9860844668446c Mo 2020-07-06 06:27:05 EDT—Mo 2020-07-13 08:50:06 EDT
 -1 33dbf8e6b9de4113a591c4f487d0ac37 Mo 2020-07-13 04:50:33 EDT— Do 2020-07-16 13:49:32 EDT
  0 75c9b70913934748b5396b3b172bee50 Mo 2020-07-20 08:43:01 EDT–Fr 2020-07-24 12:44:06 EDT

Die neueste Boot-ID wird unten angezeigt; es ist die lange, zufällige Hexadezimalzahl. Sie können diese Daten verwenden, um die Journale für einen bestimmten Start anzuzeigen. Dies kann mithilfe der Boot-Offset-Nummer in der Spalte ganz links oder der UUID in der zweiten Spalte angegeben werden. Dieser Befehl zeigt das Journal für die Boot-Instanz mit dem Offset von -2 an – der vorletzte Start vom aktuellen:

[root@testvm1 ~]# journalctl -b -2
-- Protokolle beginnen am Mo. 2020-06-08 07:47:20 EDT und enden am Fr. 2020-07-24 12:44:06 SOMMERZEIT. --
06. Juli 06:27:05 Kernel testvm1.both.org:Linux-Version 5.7.6-201.fc32.x86_64 ([email protected]) (gcc-Version 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 Möglichkeit. 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

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

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. Das -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 Befehl:

[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 Datei. 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.

Final thoughts

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