Linux Professional Institute Learning Logo.
Weiter zum Inhalt
  • Home
    • Alle Ressourcen
    • LPI Lernmaterialien
    • Mitmachen
    • Publishing Partner
    • Publishing Partner werden
    • Über uns
    • FAQ
    • Mitwirkende
    • Roadmap
    • Kontakt
  • LPI.org
108.2 Lektion 2
Thema 105: Shells und Shell-Skripte
105.1 Die Shell-Umgebung anpassen und verwenden
  • 105.1 Lektion 1
  • 105.1 Lektion 2
  • 105.1 Lektion 3
105.2 Einfache Skripte anpassen oder schreiben
  • 105.2 Lektion 1
  • 105.2 Lektion 2
Thema 106: Benutzerschnittstellen und Desktops
106.1 X11 installieren und konfigurieren
  • 106.1 Lektion 1
106.2 Grafische Desktops
  • 106.2 Lektion 1
106.3 Barrierefreiheit
  • 106.3 Lektion 1
Thema 107: Administrative Aufgaben
107.1 Benutzer- und Gruppenkonten und dazugehörige Systemdateien verwalten
  • 107.1 Lektion 1
  • 107.1 Lektion 2
107.2 Systemadministrationsaufgaben durch Einplanen von Jobs automatisieren
  • 107.2 Lektion 1
  • 107.2 Lektion 2
107.3 Lokalisierung und Internationalisierung
  • 107.3 Lektion 1
Thema 108: Grundlegende Systemdienste
108.1 Die Systemzeit verwalten
  • 108.1 Lektion 1
  • 108.1 Lektion 2
108.2 Systemprotokollierung
  • 108.2 Lektion 1
  • 108.2 Lektion 2
108.3 Grundlagen von Mail Transfer Agents (MTA)
  • 108.3 Lektion 1
108.4 Drucker und Druckvorgänge verwalten
  • 108.4 Lektion 1
Thema 109: Netzwerkgrundlagen
109.1 Grundlagen von Internetprotokollen
  • 109.1 Lektion 1
  • 109.1 Lektion 2
109.2 Persistente Netzwerkkonfiguration
  • 109.2 Lektion 1
  • 109.2 Lektion 2
109.3 Grundlegende Netzwerkfehlerbehebung
  • 109.3 Lektion 1
  • 109.3 Lektion 2
109.4 Clientseitiges DNS konfigurieren
  • 109.4 Lektion 1
Thema 110: Sicherheit
110.1 Administrationsaufgaben für Sicherheit durchführen
  • 110.1 Lektion 1
110.2 Einen Rechner absichern
  • 110.2 Lektion 1
110.3 Daten durch Verschlüsselung schützen
  • 110.3 Lektion 1
  • 110.3 Lektion 2
How to get certified
  1. Thema 108: Grundlegende Systemdienste
  2. 108.2 Systemprotokollierung
  3. 108.2 Lektion 2

108.2 Lektion 2

Zertifikat:

LPIC-1

Version:

5.0

Thema:

108 Grundlegende Systemdienste

Lernziel:

108.2 Systemprotokollierung

Lektion:

2 von 2

Einführung

Mit der allgemeinen Übernahme von systemd durch alle größeren Distributionen ist der Journal-Daemon (systemd-journald) zum Standard-Logging-Dienst geworden. In dieser Lektion werden wir ihn für folgende Aufgaben nutzen: abfragen, seine Informationen nach verschiedenen Kriterien filtern, seinen Speicher und seine Größe konfigurieren, alte Daten löschen, seine Daten von einem Rettungssystem oder einer Dateisystemkopie abrufen und — nicht zuletzt — seine Interaktion mit rsyslogd verstehen.

Grundlagen von systemd

Erstmals in Fedora eingeführt, hat systemd nach und nach SysV Init als Standard-System- und Dienstmanager in den meisten größeren Linux-Distributionen abgelöst. Zu seinen Stärken gehören unter anderem:

  • Einfache Konfiguration (Unit-Dateien im Gegensatz zu SysV-Init-Skripten).

  • Vielseitige Verwaltung (neben Daemons und Prozessen verwaltet er auch Geräte, Sockets und Einhängepunkte).

  • Abwärtskompatibilität mit SysV Init und Upstart.

  • Paralleles Laden während des Bootvorgangs (Dienste werden parallel geladen, im Gegensatz zu SysV Init, der diese sequentiell lädt).

  • Eigener Logging-Dienst namens journal, der die folgenden Vorteile bietet:

    • Zentralisiert alle Logs an einem Ort.

    • Keine Log-Rotation erforderlich.

    • Logs können deaktiviert, ins RAM geladen oder persistent gemacht werden.

Units und Targets

systemd arbeitet mit Units. Eine Unit ist jede Ressource, die systemd verwalten kann (z.B. Netzwerk, Bluetooth etc.). Units wiederum werden von Unit-Dateien verwaltet, einfachen Textdateien in /lib/systemd/system mit Konfigurationseinstellungen — in Form von Sections und Directives — für eine bestimmte Ressource. Es gibt eine Reihe von Unit-Typen: service, mount, automount, swap, timer, device, socket,path, timer, snapshot, slice, scope und target — und jeder Unit-Dateiname folgt dem Muster <Ressourcenname>.<Unit-Typ> (z.B. reboot.service).

Ein Target ist eine spezielle Art von Unit, die den klassischen Runlevels von SysV Init ähnelt. Das liegt daran, dass eine Target Unit verschiedene Ressourcen zusammenfasst, um einen bestimmten Systemzustand zu repräsentieren (z.B. ist graphical.target dem runlevel 5 ähnlich usw.). Um das aktuelle Target in Ihrem System zu überprüfen, nutzen Sie den Befehl systemctl get-default:

carol@debian:~$ systemctl get-default
graphical.target

Andererseits unterscheiden sich Targets und Runlevel darin, dass Targets einander einschließen, Runlevel jedoch nicht. So kann ein Target andere Targets aufrufen — was bei Runlevels nicht möglich ist.

Note

Die Erläuterung von systemd-Units ist nicht Thema dieser Lektion.

Das System-Journal: systemd-journald

systemd-journald ist der Systemdienst für den Empfang von Logging-Informationen aus einer Vielzahl von Quellen: Kernelmeldungen, einfache und strukturierte Systemmeldungen, Standardausgaben und Standardfehler von Diensten sowie Audit-Aufzeichnungen aus dem Kernel-Audit-Subsystem (Details dazu in der Manpage für systemd-journald). Seine Aufgabe besteht darin, ein strukturiertes und indiziertes Journal zu erstellen und zu pflegen.

Die Konfigurationsdatei ist /etc/systemd/journald.conf. Wie bei jedem anderen Dienst nutzen Sie den Befehl systemctl, um ihn zu starten, neu zu starten, zu stoppen oder einfach seinen Status zu überprüfen:

root@debian:~# systemctl status systemd-journald
 systemd-journald.service - Journal Service
   Loaded: loaded (/lib/systemd/system/systemd-journald.service; static; vendor preset: enabled)
   Active: active (running) since Sat 2019-10-12 13:43:06 CEST; 5min ago
     Docs: man:systemd-journald.service(8)
           man:journald.conf(5)
 Main PID: 178 (systemd-journal)
   Status: "Processing requests..."
    Tasks: 1 (limit: 4915)
   CGroup: /system.slice/systemd-journald.service
           └─178 /lib/systemd/systemd-journald
(...)

Konfigurationsdateien des Typs journal.conf.d/*.conf, die paketspezifische Konfigurationen enthalten können, sind ebenfalls möglich (lesen Sie dazu die Manpage von journald.conf).

Wenn aktiviert, wird das Journal entweder persistent auf der Festplatte oder flüchtig in einem RAM-basierten Dateisystem gespeichert. Das Journal ist keine reine Textdatei, sondern binär. Daher helfen keine Tools wie less oder more, um seinen Inhalt zu lesen — vielmehr nutzen Sie dafür den Befehl journalctl.

Abfrage des Journal-Inhalts

journalctl ist das Dienstprogramm, mit dem Sie das systemd-Journal abfragen — entweder als root oder mit sudo. Ohne Optionen gibt es das gesamte Journal chronologisch aus, mit den ältesten Einträgen zuerst:

root@debian:~# journalctl
-- Logs begin at Sat 2019-10-12 13:43:06 CEST, end at Sat 2019-10-12 14:19:46 CEST. --
Oct 12 13:43:06 debian kernel: Linux version 4.9.0-9-amd64 (debian-kernel@lists.debian.org) (...)
Oct 12 13:43:06 debian kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-4.9.0-9-amd64 root=UUID=b6be6117-5226-4a8a-bade-2db35ccf4cf4 ro qu
(...)

Spezifischere Abfragen führen Sie mit einer Reihe von Optionen durch:

-r

Die Meldungen des Journals erscheinen in umgekehrter Reihenfolge:

root@debian:~# journalctl -r
-- Logs begin at Sat 2019-10-12 13:43:06 CEST, end at Sat 2019-10-12 14:30:30 CEST. --
Oct 12 14:30:30 debian sudo[1356]: pam_unix(sudo:session): session opened for user root by carol(uid=0)
Oct 12 14:30:30 debian sudo[1356]:    carol : TTY=pts/0 ; PWD=/home/carol ; USER=root ; COMMAND=/bin/journalctl -r
Oct 12 14:19:53 debian sudo[1348]: pam_unix(sudo:session): session closed for user root
(...)
-f

Es erscheinen die neuesten Journal-Nachrichten sowie neue Einträge, wenn diese an das Journal angehängt werden (ähnlich tail -f):

root@debian:~# journalctl -f
-- Logs begin at Sat 2019-10-12 13:43:06 CEST. --
(...)
Oct 12 14:44:42 debian sudo[1356]: pam_unix(sudo:session): session closed for user root
Oct 12 14:44:44 debian sudo[1375]:    carol : TTY=pts/0 ; PWD=/home/carol ; USER=root ; COMMAND=/bin/journalctl -f
Oct 12 14:44:44 debian sudo[1375]: pam_unix(sudo:session): session opened for user root by carol(uid=0)

(...)
-e

Springt ans Ende des Journals, so dass die neuesten Einträge im Pager sichtbar sind:

root@debian:~# journalctl -e
(...)
Oct 12 14:44:44 debian sudo[1375]:    carol : TTY=pts/0 ; PWD=/home/carol ; USER=root ; COMMAND=/bin/journalctl -f
Oct 12 14:44:44 debian sudo[1375]: pam_unix(sudo:session): session opened for user root by carol(uid=0)
Oct 12 14:45:57 debian sudo[1375]: pam_unix(sudo:session): session closed for user root
Oct 12 14:48:39 debian sudo[1378]:    carol : TTY=pts/0 ; PWD=/home/carol ; USER=root ; COMMAND=/bin/journalctl -e
Oct 12 14:48:39 debian sudo[1378]: pam_unix(sudo:session): session opened for user root by carol(uid=0)
-n <value>, --lines=<value>

Gibt die letzten Zeilen entsprechend <value> (Wert) aus — wenn kein <value> angegeben ist, beträgt der Standardwert 10:

root@debian:~# journalctl -n 5
(...)
Oct 12 14:44:44 debian sudo[1375]:    carol : TTY=pts/0 ; PWD=/home/carol ; USER=root ; COMMAND=/bin/journalctl -f
Oct 12 14:44:44 debian sudo[1375]: pam_unix(sudo:session): session opened for user root by carol(uid=0)
Oct 12 14:45:57 debian sudo[1375]: pam_unix(sudo:session): session closed for user root
Oct 12 14:48:39 debian sudo[1378]:    carol : TTY=pts/0 ; PWD=/home/carol ; USER=root ; COMMAND=/bin/journalctl -e
Oct 12 14:48:39 debian sudo[1378]: pam_unix(sudo:session): session opened for user root by carol(uid=0)
-k, --dmesg

Äquivalent zum Befehl dmesg:

root@debian:~# journalctl -k
-- Logs begin at Sat 2019-10-12 13:43:06 CEST, end at Sat 2019-10-12 14:53:20 CEST. --
Oct 12 13:43:06 debian kernel: Linux version 4.9.0-9-amd64 (debian-kernel@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18
Oct 12 13:43:06 debian kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-4.9.0-9-amd64 root=UUID=b6be6117-5226-4a8a-bade-2db35ccf4cf4 ro qu
Oct 12 13:43:06 debian kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
Oct 12 13:43:06 debian kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
(...)
Im Journal navigieren und suchen

Sie können in der Ausgabe des Journals navigieren:

  • PageUp, PageDown und Pfeiltasten zum Bewegen nach oben, unten, links und rechts.

  • > geht ans Ende der Ausgabe.

  • < geht an den Anfang der Ausgabe.

Sie können nach Zeichenfolgen sowohl vorwärts als auch rückwärts von der aktuellen Ansichtsposition aus suchen:

  • Suche vorwärts: Drücken Sie / und geben Sie die zu suchende Zeichenfolge ein, dann drücken Sie die Eingabetaste.

  • Suche rückwärts: Drücken Sie ? und geben Sie die zu suchende Zeichenfolge ein, dann drücken Sie die Eingabetaste.

Um während der Suche durch die Übereinstimmungen zu navigieren, nutzen Sie N (zum nächsten Treffer) bzw. Umschalt+N (zum vorherigen Treffer).

Journal-Daten filtern

Im Journal können Sie die Logging-Ddaten nach verschiedenen Kriterien filtern:

Boot-Nummer
--list-boots

Listet alle verfügbaren Boot-Einträge. Die Ausgabe besteht aus drei Spalten: Boot-Nummer (0 steht für den aktuellen Boot-Eintrag, -1 den vorherigen, -2 den vorletzten usw.), Boot-ID und Zeitstempel:

root@debian:~# journalctl --list-boots
 0 83df3e8653474ea5aed19b41cdb45b78 Sat 2019-10-12 18:55:41 CEST—Sat 2019-10-12 19:02:24 CEST
-b, --boot

Zeigt alle Meldungen aus dem aktuellen Bootvorgang. Um Lognachrichten früherer Boot-Vorgänge zu sehen, fügen Sie einfach einen Offset-Parameter, wie oben erläutert, hinzu. Um zum Beispiel die Meldungen des vorherigen Boot-Vorgangs zu sehen, geben Sie journalctl -b -1 ein. Denken Sie jedoch daran, dass zur Wiederherstellung von Informationen aus früheren Logs die Persistenz des Journals aktiviert sein muss (wie das geschieht, erfahren Sie im nächsten Abschnitt):

root@debian:~# journalctl -b -1
Specifying boot ID has no effect, no persistent journal was found
Priorität
-p

Interessanterweise filtern Sie mit der Option -p auch nach Schweregrad/Priorität:

root@debian:~# journalctl -b -0 -p err
-- No entries --

Das Journal zeigt, dass bislang keine Meldungen mit der Priorität “Fehler” (err) oder höher vom aktuellen Boot-Vorgang ausgegangen sind. Hinweis: -b -0 lassen Sie weg, wenn es um den aktuellen Boot-Vorgang geht.

Note

Eine vollständige Liste aller syslog-Schweregrade (oder Prioritäten) finden Sie in der vorangegangenen Lektion.

Zeitintervall

Mit den Optionen --since und --until gibt journalctl nur Nachrichten aus, die innerhalb eines bestimmten Zeitrahmens protokolliert wurden. Die Datumsangabe sollte dem Format YYYY-MM-DD HH:MM:SS folgen. Ohne Angabe der Uhrzeit wird Mitternacht angenommen, ohne Datum der aktuelle Tag. Um z.B. Nachrichten zu sehen, die von 19:00 Uhr bis 19:01 Uhr protokolliert wurden:

root@debian:~# journalctl --since "19:00:00" --until "19:01:00"
-- Logs begin at Sat 2019-10-12 18:55:41 CEST, end at Sat 2019-10-12 20:10:50 CEST. --
Oct 12 19:00:14 debian systemd[1]: Started Run anacron jobs.
Oct 12 19:00:14 debian anacron[1057]: Anacron 2.3 started on 2019-10-12
Oct 12 19:00:14 debian anacron[1057]: Normal exit (0 jobs run)
Oct 12 19:00:14 debian systemd[1]: anacron.timer: Adding 2min 47.988096s random time.

Ebenso können Sie eine alternative Zeitangabe verwenden: "<Zahl> <Zeiteinheit> ago". Um so Nachrichten zu sehen, die vor zwei Minuten protokolliert wurden, geben Sie ein: sudo journalctl --since "2 minutes ago". Auch + und - sind für Angaben relativ zur aktuellen Zeit möglich: --since "-2 minutes" und --since "2 Minuten vor" sind gleichwertig.

Neben numerischen Ausdrücken gelten auch einige Schlüsselwörter:

yesterday

Ab Mitternacht des Vortages des aktuellen Tages.

today

Ab Mitternacht des aktuellen Tages.

tomorrow

Ab Mitternacht des Tages nach dem aktuellen Tag.

now

Die aktuelle Zeit.

Lassen Sie uns alle Nachrichten seit letzter Mitternacht bis heute um 21:00 Uhr sehen:

root@debian:~# journalctl --since "today" --until "21:00:00"
-- Logs begin at Sat 2019-10-12 20:45:29 CEST, end at Sat 2019-10-12 21:06:15 CEST. --
Oct 12 20:45:29 debian sudo[1416]:    carol : TTY=pts/0 ; PWD=/home/carol ; USER=root ; COMMAND=/bin/systemctl r
Oct 12 20:45:29 debian sudo[1416]: pam_unix(sudo:session): session opened for user root by carol(uid=0)
Oct 12 20:45:29 debian systemd[1]: Stopped Flush Journal to Persistent Storage.
(...)
Note

Mehr über die Syntax von Zeitangaben finden Sie in der Manpage systemd.time.

Programm

Um Journal-Meldungen zu sehen, die sich auf eine bestimmte ausführbare Datei beziehen, nutzen Sie die folgende Syntax: journalctl </path/to/executable>:

root@debian:~# journalctl /usr/sbin/sshd
-- Logs begin at Sat 2019-10-12 20:45:29 CEST, end at Sat 2019-10-12 21:54:49 CEST. --
Oct 12 21:16:28 debian sshd[1569]: Accepted password for carol from 192.168.1.65 port 34050 ssh2
Oct 12 21:16:28 debian sshd[1569]: pam_unix(sshd:session): session opened for user carol by (uid=0)
Oct 12 21:16:54 debian sshd[1590]: Accepted password for carol from 192.168.1.65 port 34052 ssh2
Oct 12 21:16:54 debian sshd[1590]: pam_unix(sshd:session): session opened for user carol by (uid=0)
Unit

Denken Sie daran, dass eine Unit jede Ressource ist, die systemd verwaltet. Sie können auch danach filtern.

-u

Zeigt Meldungen zu einem bestimmten Gerät:

root@debian:~# journalctl -u ssh.service
-- Logs begin at Sun 2019-10-13 10:50:59 CEST, end at Sun 2019-10-13 12:22:59 CEST. --
Oct 13 10:51:00 debian systemd[1]: Starting OpenBSD Secure Shell server...
Oct 13 10:51:00 debian sshd[409]: Server listening on 0.0.0.0 port 22.
Oct 13 10:51:00 debian sshd[409]: Server listening on :: port 22.
(...)
Note

Um alle geladenen und aktiven Units auszugeben, verwenden Sie systemctl list-units — für alle installierten Unit-Dateien systemctl list-unit-files.

Felder

Das Journal kann auch nach bestimmten Fields (Feldern) mit folgender Syntax filtern:

  • <field-name>=<value>

  • _<field-name>=<value>_

  • __<field-name>=<value>

    PRIORITY=

    Einer von acht möglichen syslog-Prioritätswerten als dezimale Zeichenfolge:

    root@debian:~# journalctl PRIORITY=3
    -- Logs begin at Sun 2019-10-13 10:50:59 CEST, end at Sun 2019-10-13 14:30:50 CEST. --
    Oct 13 10:51:00 debian avahi-daemon[314]: chroot.c: open() failed: No such file or directory

    Beachten Sie, dass Sie dieselbe Ausgabe auch mit dem oben gezeigten Befehl sudo journalctl -p err erhalten.

    SYSLOG_FACILITY=

    Eine der möglichen Facility-Codenummern als Dezimalzahl. Um etwa alle Meldungen der Benutzerebene zu sehen:

    root@debian:~# journalctl SYSLOG_FACILITY=1
    -- Logs begin at Sun 2019-10-13 10:50:59 CEST, end at Sun 2019-10-13 14:42:52 CEST. --
    Oct 13 10:50:59 debian mtp-probe[227]: checking bus 1, device 2: "/sys/devices/pci0000:00/0000:00:06.0/usb1/1-1"
    Oct 13 10:50:59 debian mtp-probe[227]: bus: 1, device: 2 was not an MTP device
    Oct 13 10:50:59 debian mtp-probe[238]: checking bus 1, device 2: "/sys/devices/pci0000:00/0000:00:06.0/usb1/1-1"
    Oct 13 10:50:59 debian mtp-probe[238]: bus: 1, device: 2 was not an MTP device
    _PID=

    Zeigt Meldungen von einer bestimmten Prozess-ID. Um alle von systemd erzeugten Meldungen zu sehen:

    root@debian:~# journalctl _PID=1
    -- Logs begin at Sun 2019-10-13 10:50:59 CEST, end at Sun 2019-10-13 14:50:15 CEST. --
    Oct 13 10:50:59 debian systemd[1]: Mounted Debug File System.
    Oct 13 10:50:59 debian systemd[1]: Mounted POSIX Message Queue File System.
    Oct 13 10:50:59 debian systemd[1]: Mounted Huge Pages File System.
    Oct 13 10:50:59 debian systemd[1]: Started Remount Root and Kernel File Systems.
    Oct 13 10:50:59 debian systemd[1]: Starting Flush Journal to Persistent Storage...
    (...)
    _BOOT_ID

    Anhand der Boot-ID filtern Sie die Meldungen eines bestimmten Boot-Vorgangs, zum Beispiel: sudo journalctl _BOOT_ID=83df3e8653474ea5aed19b41cdb45b78.

    _TRANSPORT

    Zeigt Nachrichten von einem bestimmten Transport. Mögliche Werte sind: audit (Kernel-Audit-Subsystem), driver (intern generiert), syslog (Syslog-Socket), journal (natives Journal-Protokoll), stdout (Standardausgabe der Dienste oder Standardfehler), kernel (Kernel-Ring Buffer — das gleiche wie dmesg, journalctl -k oder journalctl --dmesg):

    root@debian:~# journalctl _TRANSPORT=journal
    -- Logs begin at Sun 2019-10-13 20:19:58 CEST, end at Sun 2019-10-13 20:46:36 CEST. --
    Oct 13 20:19:58 debian systemd[1]: Started Create list of required static device nodes for the current kernel.
    Oct 13 20:19:58 debian systemd[1]: Starting Create Static Device Nodes in /dev...
    Oct 13 20:19:58 debian systemd[1]: Started Create Static Device Nodes in /dev.
    Oct 13 20:19:58 debian systemd[1]: Starting udev Kernel Device Manager...
    (...)
Felder kombinieren

Die Felder schließen sich nicht gegenseitig aus, so dass Sie mehrere in derselben Abfrage verwenden können. Es werden dann nur Nachrichten angezeigt, die mit dem Wert beider Felder übereinstimmen:

root@debian:~# journalctl PRIORITY=3 SYSLOG_FACILITY=0
-- No entries --
root@debian:~# journalctl PRIORITY=4 SYSLOG_FACILITY=0
-- Logs begin at Sun 2019-10-13 20:19:58 CEST, end at Sun 2019-10-13 20:21:55 CEST. --
Oct 13 20:19:58 debian kernel: acpi PNP0A03:00: fail to add MMCONFIG information, can't access extended PCI configuration (...)

Es sei denn, Sie verwenden das Trennzeichen +, um zwei Ausdrücke in der Art eines logischen OR zu kombinieren:

root@debian:~# journalctl PRIORITY=3 + SYSLOG_FACILITY=0
-- Logs begin at Sun 2019-10-13 20:19:58 CEST, end at Sun 2019-10-13 20:24:02 CEST. --
Oct 13 20:19:58 debian kernel: Linux version 4.9.0-9-amd64 (debian-kernel@lists.debian.org) (...9
Oct 13 20:19:58 debian kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-4.9.0-9-amd64 root=UUID= (...)
(...)

Sie können auch zwei Werte für dasselbe Feld angeben, so dass alle Einträge erscheinen, die einem der beiden Werte entsprechen:

root@debian:~# journalctl PRIORITY=1
-- Logs begin at Sun 2019-10-13 17:16:24 CEST, end at Sun 2019-10-13 17:30:14 CEST. --
-- No entries --
root@debian:~# journalctl PRIORITY=1 PRIORITY=3
-- Logs begin at Sun 2019-10-13 17:16:24 CEST, end at Sun 2019-10-13 17:32:12 CEST. --
Oct 13 17:16:27 debian connmand[459]: __connman_inet_get_pnp_nameservers: Cannot read /pro
Oct 13 17:16:27 debian connmand[459]: The name net.connman.vpn was not provided by any .se
Note

Journalfelder fallen in eine der folgenden Kategorien: “User Journal Fields”, “Trusted Journal Fields”, “Kernel Journal Fields”, “Fields on behalf of a different program” und “Address Fields”. Weitere Informationen zu diesem Thema — einschließlich einer vollständigen Liste der Felder — finden Sie in der Manpage von systemd.journal-fields(7).

Manuelle Einträge im System-Journal: systemd-cat

So wie der Befehl logger Nachrichten von der Kommandozeile an das System-Log sendet (wie in der vorangegangenen Lektion gesehen), hat der Befehl systemd-cat für das System-Journal eine ähnliche, aber vielseitigere Aufgabe. Er erlaubt uns, Standardeingaben (stdin), -ausgaben (stdout) und -fehler (stderr) an das Journal zu senden.

Ohne Parameter aufgerufen, sendet er stdin vollständig an das Journal. Sie beenden den Vorgang mit Strg+C:.

carol@debian:~$ systemd-cat
This line goes into the journal.
^C

Auch die Ausgabe eines Pipe-Befehls wird an das Journal gesendet:

carol@debian:~$ echo "And so does this line." | systemd-cat

Wenn ein Befehl folgt, geht dessen Ausgabe ebenfalls an das Journal — zusammen mit stderr (falls vorhanden):

carol@debian:~$ systemd-cat echo "And so does this line too."

Mit der Option -p geben Sie eine Prioritätsstufe an:

carol@debian:~$ systemd-cat -p emerg echo "This is not a real emergency."

Lesen Sie die Manpage von systemd-cat, um mehr über seine Optionen zu erfahren.

Um die letzten vier Zeilen im Journal zu sehen:

carol@debian:~$ journalctl -n 4
(...)
-- Logs begin at Sun 2019-10-20 13:43:54 CEST. --
Nov 13 23:14:39 debian cat[1997]: This line goes into the journal.
Nov 13 23:19:16 debian cat[2027]: And so does this line.
Nov 13 23:23:21 debian echo[2030]: And so does this line too.
Nov 13 23:26:48 debian echo[2034]: This is not a real emergency.
Note

Journaleinträge mit der Prioritätsstufe emergency (Notfall) werden auf den meisten Systemen fett und rot ausgegeben.

Persistente Journalspeicherung

Wie bereits erwähnt, gibt es drei mögliche Orte für das Journal:

  • Das Journaling ist ganz abgeschaltet (Umleitung auf andere Einrichtungen wie z.B. die Konsole sind aber weiterhin möglich).

  • Es bleibt im Speicher — was es flüchtig macht --, und die Logs gehen bei jedem Systemneustart verloren. In diesem Szenario wird das Verzeichnis /run/log/journal erstellt und verwendet.

  • Es ist persistent, so dass Logs auf die Festplatte geschrieben werden — in diesem Fall in das Verzeichnis /var/log/journal.

Das Standardverhalten sieht wie folgt aus: Wenn /var/log/journal/ nicht existiert, werden die Logs flüchtig in einem Verzeichnis in /run/log/journal/ gespeichert und gehen beim Neustart verloren. Der Name des Verzeichnisses (/etc/machine-id) ist eine mit Zeilenumbruch endende, hexadezimale, 32-stellige Zeichenkette aus Zahlen und Kleinbuchstaben:

carol@debian:~$ ls /run/log/journal/8821e1fdf176445697223244d1dfbd73/
system.journal

Wenn Sie versuchen, es mit less zu lesen, erhalten Sie eine Warnung — nutzen Sie stattdessen den Befehl journalctl:

root@debian:~# less /run/log/journal/9a32ba45ce44423a97d6397918de1fa5/system.journal
"/run/log/journal/9a32ba45ce44423a97d6397918de1fa5/system.journal" may be a binary file.  See it anyway?
root@debian:~# journalctl
-- Logs begin at Sat 2019-10-05 21:26:38 CEST, end at Sat 2019-10-05 21:31:27 CEST. --
(...)
Oct 05 21:26:44 debian systemd-journald[1712]: Runtime journal (/run/log/journal/9a32ba45ce44423a97d6397918de1fa5) is 4.9M, max 39.5M, 34.6M free.
Oct 05 21:26:44 debian systemd[1]: Started Journal Service.
(...)

Wenn /var/log/journal/ existiert, werden die Logs dort dauerhaft gespeichert. Sollte dieses Verzeichnis gelöscht werden, würde systemd-journald es nicht neu erstellen, sondern stattdessen in /run/log/journal schreiben. Sobald Sie /var/log/journal/ wieder erstellen und den Daemon neu starten, erfolgt wieder ein persistentes Logging:

root@debian:~# mkdir /var/log/journal/
root@debian:~# systemctl restart systemd-journald
root@debian:~# journalctl
(...)
Oct 05 21:33:49 debian systemd-journald[1712]: Received SIGTERM from PID 1 (systemd).
Oct 05 21:33:49 debian systemd[1]: Stopped Journal Service.
Oct 05 21:33:49 debian systemd[1]: Starting Journal Service...
Oct 05 21:33:49 debian systemd-journald[1768]: Journal started
Oct 05 21:33:49 debian systemd-journald[1768]: System journal (/var/log/journal/9a32ba45ce44423a97d6397918de1fa5) is 8.0M, max 1.1G, 1.1G free.
Oct 05 21:33:49 debian systemd[1]: Started Journal Service.
Oct 05 21:33:49 debian systemd[1]: Starting Flush Journal to Persistent Storage...
(...)
Note

Standardmäßig gibt es für jeden angemeldeten Benutzer spezifische Journaaldateien, die sich in /var/log/journal/ befinden, so dass Sie — zusammen mit den system.journal-Dateien — auch Dateien vom Typ user-1000.journal finden.

Darüber hinaus können Sie die Art und Weise, wie der Journal-Daemon mit der Logspeicherung umgeht, auch nach der Installation in der Konfigurationsdatei anpassen: /etc/systemd/journald.conf. Die wichtigste Option ist Storage=, die die folgenden Werte haben kann:

Storage=volatile

Die Logdaten werden ausschließlich im Speicher abgelegt — unter /run/log/journal/. Falls nicht vorhanden, wird das Verzeichnis erstellt.

Storage=persistent

Standardmäßig werden die Logdaten auf der Festplatte gespeichert (unter /var/log/journal/) — mit einem Fallback auf den Speicher (/run/log/journal/) während der frühen Startphasen und wenn die Festplatte nicht beschreibbar ist. Beide Verzeichnisse werden bei Bedarf angelegt.

Storage=auto

auto verhält sich ähnlich wie persistent, aber das Verzeichnis /var/log/journal wird bei Bedarf nicht angelegt. Dies ist der Default.

Storage=none

Alle Logdaten werden verworfen. Die Weiterleitung an andere Ziele wie die Konsole, den Kernel Log Buffer oder einen Syslog-Socket ist jedoch weiterhin möglich.

Um zum Beispiel systemd-journald /var/log/journal/ erstellen zu lassen und auf persistenten Speicher umzuschalten, würden Sie /etc/systemd/journald.conf bearbeiten und Storage=persistent setzen, die Datei speichern und den Daemon mit sudo systemctl restart systemd-journald neu starten. Um sicherzugehen, dass der Neustart fehlerfrei verlaufen ist, können Sie jederzeit den Status des Daemons überprüfen:

root@debian:~# systemctl status systemd-journald
 systemd-journald.service - Journal Service
   Loaded: loaded (/lib/systemd/system/systemd-journald.service; static; vendor preset: enabled)
   Active: active (running) since Wed 2019-10-09 10:03:40 CEST; 2s ago
     Docs: man:systemd-journald.service(8)
           man:journald.conf(5)
 Main PID: 1872 (systemd-journal)
   Status: "Processing requests..."
    Tasks: 1 (limit: 3558)
   Memory: 1.1M
   CGroup: /system.slice/systemd-journald.service
           └─1872 /lib/systemd/systemd-journald

Oct 09 10:03:40 debian10 systemd-journald[1872]: Journal started
Oct 09 10:03:40 debian10 systemd-journald[1872]: System journal (/var/log/journal/9a32ba45ce44423a97d6397918de1fa5) is 8.0M, max 1.2G, 1.2G free.
Note

Die Journaldateien in /var/log/journal/<machine-id>/ oder /run/log/journal/<machine-id>/ haben die Endung .journal (z.B. system.journal). Sind sie jedoch beschädigt oder wird der Daemon unsauber gestoppt, werden sie mit dem Suffix ~ umbenannt (z.B. system.journal~), und der Daemon beginnt, in eine neue, saubere Datei zu schreiben.

Alte Journaldaten löschen: Journalgröße

Logs werden in Journaldateien gespeichert, deren Dateinamen mit .journal oder .journal~ enden und die sich im entsprechenden Verzeichnis befinden (/run/log/journal oder /var/log/journal, je nach Konfiguration). Um zu überprüfen, wie viel Speicherplatz aktuell von Journaldateien (sowohl archivierten als auch aktiven) belegt wird, nutzen Sie die Option --disk-usage:

root@debian:~# journalctl --disk-usage
Archived and active journals take up 24.0M in the filesystem.

Die systemd-Logs nehmen standardmäßig maximal 10% der Größe des Dateisystems ein, in dem sie gespeichert sind --auf einem 1-GB-Dateisystem also zum Beispiel nicht mehr als 100 MB. Sobald diese Grenze erreicht ist, werden alte Protokolle verworfen, um in der Nähe dieses Wertes zu bleiben.

Sie steuern die Größenbeschränkung für gespeicherte Journaldateien mit einer Reihe von Konfigurationsoptionen in /etc/systemd/journald.conf. Diese Optionen fallen in zwei Kategorien, je nach Dateisystemtyp: persistent (/var/log/journal) oder speicherintern (/run/log/journal). Im ersten Fall ist den Optionen das Wort System vorangestellt, und sie gelten nur, wenn das persistente Logging ordnungsgemäß aktiviert ist und das System vollständig hochgefahren ist. Im zweiten Fall beginnen die Optionsnamen mit dem Wort Runtime und gelten in den folgenden Szenarien:

SystemMaxUse=, RuntimeMaxUse=

Steuert die Menge des Festplattenplatzes, der vom Journal belegt werden kann. Der Standardwert beträgt 10% der Größe des Dateisystems, kann aber geändert werden (z.B. SystemMaxUse=500M), solange er ein Maximum von 4 GiB nicht überschreitet.

SystemKeepFree=, RuntimeKeepFree=

Steuert die Menge des Festplattenplatzes, der für andere Benutzer frei bleiben soll. Der Standardwert liegt bei 15% der Dateisystemgröße, kann aber geändert werden (z.B. SystemKeepFree=500M), solange er ein Maximum von 4GiB nicht überschreitet.

Was den Vorrang von *MaxUse und *KeepFree betrifft, wird systemd-journald beide erfüllen, indem es den kleineren der beiden Werte verwendet. Beachten Sie auch, dass nur archivierte (im Gegensatz zu aktiven) Journal-Dateien gelöscht werden.

SystemMaxFileSize=, RuntimeMaxFileSize=

Steuert die maximale Größe, auf die einzelne Journaldateien anwachsen können. Die Vorgabe ist 1/8 von *MaxUse. Die Größenreduzierung erfolgt synchron und die Werte können in Bytes oder mit K, M, G, T, P, E für Kibibytes, Mebibytes, Gibibytes, Tebibytes, Pebibytes bzw. Exbibytes angegeben werden.

SystemMaxFiles=, RuntimeMaxFiles=

Legt die maximale Anzahl der zu einzelnen zu speichernden und archivierten Journaldateien fest (aktive Journaldateien sind davon nicht betroffen). Der Standardwert ist 100.

Neben dem größenbasierten Löschen und Rotieren von Lognachrichten erlaubt systemd-journald auch zeitbasierte Kriterien: MaxRetentionSec= und MaxFileSec=. Weitere Informationen zu diesen und anderen Optionen finden Sie in der Manpage von journald.conf.

Note

Immer wenn Sie das Standardverhalten von systemd-journald durch Auskommentieren und Bearbeiten von Optionen in /etc/systemd/journald.conf ändern, müssen Sie den Daemon neu starten, damit die Änderungen wirksam werden.

Das Journal bereinigen

Sie können archivierte Journaldateien jederzeit mit einer der folgenden drei Optionen manuell bereinigen:

--vacuum-time=

Mit dieser zeitbasierten Option werden alle Nachrichten in Journaldateien mit einem Zeitstempel, der älter als der angegebene Zeitrahmen ist, gelöscht. Die Werte müssen mit einem der folgenden Suffixe geschrieben werden: s, m, h, days (oder d), months, weeks (oder w) und years (oder y). Um beispielsweise alle Nachrichten in archivierten Journaldateien loszuwerden, die älter als 1 Monat sind:

root@debian:~# journalctl --vacuum-time=1months
Deleted archived journal /var/log/journal/7203088f20394d9c8b252b64a0171e08/system@27dd08376f71405a91794e632ede97ed-0000000000000001-00059475764d46d6.journal (16.0M).
Deleted archived journal /var/log/journal/7203088f20394d9c8b252b64a0171e08/user-1000@e7020d80d3af42f0bc31592b39647e9c-000000000000008e-00059479df9677c8.journal (8.0M).
--vacuum-size=

Diese größenbasierte Option löscht archivierte Journaldateien, bis sie einen Wert unterhalb der angegebenen Größe einnehmen. Die Werte müssen mit einem der folgenden Suffixe geschrieben werden: K, M, G oder T. Um etwa archivierte Journaldateien zu eliminieren, bis diese nicht mehr als 100 Mebibits einnehmen:

root@debian:~# journalctl --vacuum-size=100M
Vacuuming done, freed 0B of archived journals from /run/log/journal/9a32ba45ce44423a97d6397918de1fa5.
--vacuum-files=

Diese Option sorgt dafür, dass nicht mehr archivierte Journaldateien als die angegebene Anzahl übrig bleiben. Der Wert ist eine ganze Zahl. Um die Anzahl der archivierten Journaldateien auf 10 zu begrenzen:

root@debian:~# journalctl --vacuum-files=10
Vacuuming done, freed 0B of archived journals from /run/log/journal/9a32ba45ce44423a97d6397918de1fa5.

Beim Bereinigen werden nur archivierte Journaldateien entfernt. Um alle loszuwerden, also auch aktive Journaldateien, müssen Sie ein Signal (SIGUSR2) verwenden, das mit der Option --rotate die sofortige Rotation der Journaldateien anfordert. Andere wichtige Signale rufen Sie über die folgenden Optionen auf:

--flush (SIGUSR1)

Fordert das Flushen der Journal-Dateien von /run/ nach /var/ an, um das Journal persistent zu machen. Er setzt voraus, dass persistentes Logging aktiviert und /var/ eingehängt ist.

--sync (SIGRTMIN+1)

Es sorgt dafür, dass alle ungeschriebenen Logdaten auf die Festplatte geschrieben werden.

Note

Um die interne Konsistenz der Journaldatei zu prüfen, nutzen Sie journalctl mit der Option --verify. Sie sehen einen Fortschrittsbalken während der Prüfung — mögliche Probleme werden ebenfalls angezeigt.

Journaldaten aus einem Rettungssystem abrufen

Als Systemadministrator befinden Sie sich möglicherweise in einer Situation, über ein Rettungssystem (eine bootfähige CD oder einen USB-Stick mit einer Live-Linux-Distribution) auf die Journaldateien auf der Festplatte eines fehlerhaften Rechners zugreifen müssen.

journalctl sucht die Journaldateien in /var/log/journal/<machine-id>/. Da die IDs auf dem Rettungs- und dem fehlerhaften System unterschiedlich sein werden, müssen Sie die folgende Option verwenden:

-D </path/to/dir>, --directory=</path/to/dir>

Damit geben Sie einen Verzeichnispfad an, in dem journalctl anstelle der standardmäßigen Laufzeit- und Systempfade nach Journaldateien suchen soll.

Dazu ist es notwendig, dass Sie das rootfs des fehlerhaften Systems (/dev/sda1) auf dem Dateisystem des Rettungssystems mounten und so mit dem Lesen der Journaldateien fortfahren:

root@debian:~# journalctl -D /media/carol/faulty.system/var/log/journal/
-- Logs begin at Sun 2019-10-20 12:30:45 CEST, end at Sun 2019-10-20 12:32:57 CEST. --
oct 20 12:30:45 suse-server kernel: Linux version 4.12.14-lp151.28.16-default (geeko@buildhost) (...)
oct 20 12:30:45 suse-server kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-4.12.14-lp151.28.16-default root=UUID=7570f67f-4a08-448e-aa09-168769cb9289 splash=>
oct 20 12:30:45 suse-server kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
oct 20 12:30:45 suse-server kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
(...)

Andere Optionen, die in diesem Szenario nützlich sein können, sind:

-m, --merge

Führt Einträge aus allen verfügbaren Journalen unter /var/log/journal zusammen, auch aus entfernten Journalen.

--file

Zeigt die Einträge in einer bestimmten Datei an, zum Beispiel: journalctl --file /var/log/journal/64319965bda04dfa81d3bc4e7919814a/user-1000.journal.

--root

Übergibt als Argument einen Verzeichnispfad, der als Wurzelverzeichnis interpretiert wird. journalctl wird dort nach Journaldateien suchen (z.B. journalctl --root /faulty.system/).

Weitere Informationen finden Sie in der Manpage von journalctl.

Logdaten an einen traditionellen syslog-Daemon weiterleiten

Sie können Logdaten aus dem Journal einem traditionellen syslog-Daemon zur Verfügung stelle, und zwar:

  • Weiterleitung von Nachrichten an die Socket-Datei /run/systemd/journal/syslog, damit syslogd diese lesen kann. Sie aktivieren dies mit der Option ForwardToSyslog=yes.

  • Sie haben einen syslog-Daemon, der sich wie journalctl verhält, also Lognachrichten direkt aus den Journaldateien liest. In diesem Fall ist Storage die relevante Option, die einen anderen Wert als none haben muss.

Note

Sie können Logmeldungen auch mit den folgenden Optionen an andere Ziele weiterleiten: ForwardToKMsg (Kernel-Logpuffer — kmsg), ForwardToConsole (Systemkonsole) oder ForwardToWall (alle eingeloggten Benutzer über wall). Weitere Informationen finden Sie in der Manpage von journald.conf.

Geführten Übungen

  1. Sie sind root — vervollständigen Sie die Tabelle mit den entsprechenden journalctl-Befehlen:

    Zweck Befehl

    Kerneleinträge anzeigen

    Meldungen des zweiten Boot ab Journalbeginn ausgeben

    Meldungen des zweiten Boot ab Ende des Journals ausgeben

    Letzte Logmeldungen ausgeben und auf neue Meldungen achten

    Nur neue Nachrichten ab jetzt ausgeben und die Ausgabe kontinuierlich aktualisieren

    Meldungen des vorherigen Boot mit der Priorität warning und in umgekehrter Reihenfolge ausgeben

  2. Das Verhalten des Journal-Daemons in Bezug auf die Speicherung wird hauptsächlich durch den Wert der Option Storage in /etc/systemd/journald.conf gesteuert. Geben Sie in der folgenden Tabelle an, welches Verhalten mit welchem Wert zusammenhängt:

    Verhalten Storage=auto Storage=none Storage=persistent Storage=volatile

    Logdaten werden verworfen, aber Weiterleitung ist möglich.

    Sobald das System hochgefahren ist, werden die Logdaten unter /var/log/journal gespeichert. Wenn das Verzeichnis nicht bereits vorhanden ist, wird es erstellt.

    Sobald das System hochgefahren ist, werden die Logdaten unter /var/log/journal gespeichert. Wenn das Verzeichnis nicht bereits vorhanden ist, wird es nicht erstellt.

    Protokolldaten werden unter /var/run/journal gespeichert, überleben aber keinen Neustart.

  3. Sie können das Journal manuell auf Basis von Zeit, Größe und Anzahl der Dateien verkleinern. Führen Sie die folgenden Aufgaben mit journalctl und den entsprechenden Optionen aus:

    • Prüfen Sie, wie viel Speicherplatz die Journaldateien beanspruchen:

    • Verringern Sie die Menge des für archivierte Journaldateien reservierten Speicherplatzes und setzen Sie ihn auf 200MiB:

    • Prüfen Sie den Speicherplatz erneut und erläutern Sie die Ergebnisse:

Offene Übungen

  1. Welche Optionen sollten Sie in /etc/systemd/journald.conf ändern, damit Nachrichten an /dev/tty5 weitergeleitet werden? Welche Werte sollten die Optionen haben?

  2. Geben Sie den richtigen journalctl-Filter an, um Folgendes auszugeben:

    Zweck Filter + Wert

    Meldungen, die zu einem bestimmten Benutzer gehören

    Meldungen von einem Rechner namens debian

    Meldungen, die zu einer bestimmten Gruppe gehören

    Meldungen, die zu root gehören

    Meldungen von sudo, basierend auf dem Pfad der ausführbaren Datei

    Meldungen von sudo, basierend auf dem Befehlsnamen

  3. Wenn Sie nach Priorität filtern, erscheinen auch Logs mit einer höheren Priorität als angegebenen — zum Beispiel gibt journalctl -p err die Meldungen error, critical, alert und emergency aus. Sie können aber auch veranlassen, dass journalctl nur einen bestimmten Bereich anzeigt. Welchen Befehl nutzen Sie, damit journalctl nur Meldungen der Prioritätsstufen warning, error und critical ausgibt?

  4. Sie können die Prioritätsstufen auch numerisch angeben. Schreiben Sie den Befehl aus der vorherigen Übung unter Verwendung der numerischen Darstellung von Prioritätsebenen:

Zusammenfassung

In dieser Lektion haben Sie gelernt:

  • Die Vorteile von systemd als System- und Dienstmanager.

  • Die Grundlagen von systemd Units und Targets.

  • Woher systemd-journald die Logdaten bezieht.

  • Die Optionen, die Sie systemctl übergeben, um systemd-journald zu steuern: start, status, restart und stop.

  • Wo sich die Konfigurationsdatei des Journals befindet (/etc/systemd/journald.conf) und welche ihre wichtigsten Optionen sind.

  • Wie Sie das Journal allgemein und mit Hilfe von Filtern nach bestimmten Daten abfragen.

  • Wie Sie durch das Journal navigieren und darin suchen.

  • Wie Sie Journaldateien sichern: im Speicher vs. auf Festplatte.

  • Wie Sie die Journalfunktion vollständig deaktivieren.

  • Wie Sie den vom Journal belegten Plattenspeicher überprüfen, Größenbeschränkungen für gespeicherte Journaldateien definieren und archivierte Journaldateien manuell bereinigen (vacuum).

  • Wie Sie Journaldaten aus einem Rettungssystem ziehen.

  • Wie Sie Logdaten an einen traditionellen syslog-Daemon weiterleiten.

In dieser Lektion verwendete Befehle:

systemctl

Steuert den System- und Dienstmanager systemd.

journalctl

Fragt das systemd-Journal ab.

ls

Listet Verzeichnisinhalte auf.

less

Zeigt Dateiinhalte an.

mkdir

Erstellt Verzeichnisse.

Lösungen zu den geführten Übungen

  1. Sie sind root — vervollständigen Sie die Tabelle mit den entsprechenden journalctl-Befehlen:

    Zweck Befehl

    Kerneleinträge anzeigen

    journalctl -k oder journalctl --dmesg

    Meldungen des zweiten Boot ab Journalbeginn ausgeben

    journalctl -b 2

    Meldungen des zweiten Boot ab Ende des Journals ausgeben

    journalctl -b -2 -r oder journalctl -r -b -2

    Letzte Logmeldungen ausgeben und auf neue Meldungen achten

    journalctl -f

    Nur neue Nachrichten ab jetzt ausgeben und die Ausgabe kontinuierlich aktualisieren

    journalctl --since "now" -f

    Meldungen des vorherigen Boot mit der Priorität warning und in umgekehrter Reihenfolge ausgeben

    journalctl -b -1 -p warning -r

  2. Das Verhalten des Journal-Daemons in Bezug auf die Speicherung wird hauptsächlich durch den Wert der Option Storage in /etc/systemd/journald.conf gesteuert. Geben Sie in der folgenden Tabelle an, welches Verhalten mit welchem Wert zusammenhängt:

    Verhalten Storage=auto Storage=none Storage=persistent Storage=volatile

    Logdaten werden verworfen, aber Weiterleitung ist möglich.

    x

    Sobald das System hochgefahren ist, werden die Protokolldaten unter /var/log/journal gespeichert. Wenn das Verzeichnis noch nicht vorhanden ist, wird es angelegt.

    x

    Sobald das System hochgefahren ist, werden die Protokolldaten unter /var/log/journal gespeichert. Wenn das Verzeichnis nicht bereits vorhanden ist, wird es nicht angelegt.

    x

    Protokolldaten werden unter /var/run/journal gespeichert, überleben aber keinen Neustart.

    x

  3. Sie können das Journal manuell auf Basis von Zeit, Größe und Anzahl der Dateien verkleinern. Führen Sie die folgenden Aufgaben mit journalctl und den entsprechenden Optionen aus:

    • Prüfen Sie, wie viel Speicherplatz die Journaldateien beanspruchen:

      journalctl --disk-usage
    • Verringern Sie die Menge des für archivierte Journaldateien reservierten Speicherplatzes und setzen Sie ihn auf 200MiB:

      journalctl --vacuum-size=200M
    • Prüfen Sie den Speicherplatz erneut und erläutern Sie die Ergebnisse:

      journalctl --disk-usage

      Es besteht kein Zusammenhang, da --disk-usage den von aktiven und archivierten Journaldateien belegten Platz anzeigt, während --vacuum-size nur für archivierte Dateien gilt.

Lösungen zu den offenen Übungen

  1. Welche Optionen sollten Sie in /etc/systemd/journald.conf ändern, damit Nachrichten an /dev/tty5 weitergeleitet werden? Welche Werte sollten die Optionen haben?

    ForwardToConsole=yes
    TTYPath=/dev/tty5
  2. Geben Sie den richtigen journalctl-Filter an, um Folgendes auszugeben:

    Zweck Filter + Wert

    Meldungen, die zu einem bestimmten Benutzer gehören

    _ID=<user-id>

    Meldungen von einem Rechner namens debian

    _HOSTNAME=debian

    Meldungen, die zu einer bestimmten Gruppe gehören

    _GID=<group-id>

    Meldungen, die zu root gehören

    _UID=0

    Meldungen von sudo, basierend auf dem Pfad der ausführbaren Datei

    _EXE=/usr/bin/sudo

    Meldungen von sudo, basierend auf dem Befehlsnamen

    _COMM=sudo

  3. Wenn Sie nach Priorität filtern, erscheinen auch Logs mit einer höheren Priorität als angegebenen — zum Beispiel gibt journalctl -p err die Meldungen error, critical, alert und emergency aus. Sie können aber auch veranlassen, dass journalctl nur einen bestimmten Bereich anzeigt. Welchen Befehl nutzen Sie, damit journalctl nur Meldungen der Prioritätsstufen warning, error und critical ausgibt?

    journalctl -p warning..crit
  4. Sie können die Prioritätsstufen auch numerisch angeben. Schreiben Sie den Befehl aus der vorherigen Übung unter Verwendung der numerischen Darstellung von Prioritätsebenen:

    journalctl -p 4..2

Linux Professional Insitute Inc. Alle Rechte vorbehalten. Besuchen Sie die LPI Learning Website: https://learning.lpi.org
Dieses Werk steht unter der Lizenz Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International.

Nächste Lektion

108.3 Grundlagen von Mail Transfer Agents (MTA) (108.3 Lektion 1)

Nächste Lektion lesen

Linux Professional Insitute Inc. Alle Rechte vorbehalten. Besuchen Sie die LPI Learning Website: https://learning.lpi.org
Dieses Werk steht unter der Lizenz Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International.

LPI ist eine Non-Profit-Organisation.

© 2022 Linux Professional Institute (LPI) ist eine globale Organisation für Zertifizierungsstandards und zur Karriereplanung für Open-Source-Profis. Mit mehr als 200.000 Zertifikatsinhabern ist es die weltweit erste und größte herstellerneutrale Linux- und Open-Source-Zertifizierungsstelle. LPI verfügt über zertifizierte Fachleute in über 180 Ländern, bietet Prüfungen in mehreren Sprachen an und hat Hunderte von Trainingspartnern.

Unser Ziel ist es, wirtschaftliche und kreative Möglichkeiten für alle zu ermöglichen, indem wir Open-Source-Wissens- und Kompetenzzertifizierungen allgemein zugänglich machen.

  • LinkedIn
  • flogo-RGB-HEX-Blk-58 Facebook
  • Twitter
  • Kontaktieren Sie uns
  • Datenschutz und Cookie-Richtlinien

Haben Sie einen Fehler entdeckt oder möchten Sie helfen, diese Seite zu verbessern? Lassen Sie es uns wissen.

© 1999–2022 The Linux Professional Institute Inc. Alle Rechte vorbehalten.