Ubuntu Manpage: journald.conf, journald.conf.d, journald@.conf

BEZEICHNUNG

       journald.conf, journald.conf.d, journald@.conf - Journal-Dienst-Konfigurationsdateien

ÜBERSICHT

           /etc/systemd/journald.conf
           /run/systemd/journald.conf
           /usr/local/lib/systemd/journald.conf
           /usr/lib/systemd/journald.conf
           /etc/systemd/journald.conf.d/*.conf
           /run/systemd/journald.conf.d/*.conf
           /usr/local/lib/systemd/journald.conf.d/*.conf
           /usr/lib/systemd/journald.conf.d/*.conf
           /etc/systemd/journald@NAMENSRAUM.conf
           /etc/systemd/journald@NAMENSRAUM.conf.d/*.conf
           /run/systemd/journald@NAMENSRAUM.conf.d/*.conf
           /usr/local/lib/systemd/journald@NAMENSRAUM.conf.d/*.conf
           /usr/lib/systemd/journald@NAMENSRAUM.conf.d/*.conf

BESCHREIBUNG

       Diese Dateien konfigurieren verschiedene Parameter des Systemd-Journal-Dienstes
       systemd-journald.service(8). Siehe systemd.syntax(7) für eine allgemeine Beschreibung der Syntax.

       Die systemd-journald-Instanz, die den Vorgabe-Namensraum verwaltet, wird in /etc/systemd/journald.conf
       und zugeordneten Ergänzungen konfiguriert. Instanzen, die andere Namensräume verwalten, lesen
       /etc/systemd/journald@NAMENSRAUM.conf und zugeordnete Ergänzungen, wobei der Namensraumkennzeichner
       eingefüllt wird. Dies ermöglicht es jedem Namensraum, eine eigenständige Konfiguration zu transportieren.
       Lesen Sie systemd-journald.service(8) für Details über Journal-Namensräume.

KONFIGURATIONSVERZEICHNISSE UND RANGFOLGE

Die Standardkonfiguration wird während der Kompilierung gesetzt. Daher wird eine Konfiguration nur
benötigt, wenn von diesen Vorgaben abgewichen werden muss. Die Hauptkonfigurationsdatei wird aus einem
der aufgeführten Verzeichnisse in der Prioritätsreihenfolge geladen, nur die zuerst gefundene Datei wird
verwandt: /etc/systemd/, /run/systemd/, /usr/local/lib/systemd/ [1], /usr/lib/systemd/. Die
Lieferantenversion der Datei enthält die Vorgaben als auskommentierte Hinweise für den Administrator.
Lokal können diese Einstellungen durch die Erstellung von Ergänzungen, wie nachfolgend beschrieben, außer
Kraft gesetzt werden. Zu diesem Zweck kann die Hauptkonfigurationsdatei (oder eine Kopie in /etc/, falls
sie in /usr/ ausgeliefert wird) auch bearbeitet werden, allerdings wird empfohlen, Ergänzungen für lokale
Konfiguration zu verwenden, statt die Hauptkonfigurationsdatei zu verändern.

Zusätzlich zu der Hauptkonfigurationsdatei, werden Ergänzungs-Konfigurationsschnipsel aus
/usr/lib/systemd/*.conf.d/, /usr/local/lib/systemd/*.conf.d/ und /etc/systemd/*.conf.d/ gelesen. Diese
Ergänzungen haben Vorrang vor der Hauptkonfigurationsdatei und setzen diese außer Kraft. Dateien in den
Konfigurationsunterverzeichnissen *.conf.d/ werden in lexikographischer Reihenfolge nach ihrem Dateinamen
sortiert, unabhängig davon, in welchem Unterverzeichnis sie sich befinden. Bei Optionen, die nur einen
einzelnen Wert akzeptieren, hat der Eintrag in der Datei, die als letztes in der Sortierung folgt,
Vorrang, falls mehrere Dateien die gleiche Option angeben. Bei Optionen, die eine Liste von Werten
akzeptieren, werden Einträge gesammelt, wie sie in den sortierten Dateien auftauchen.

Wenn Pakete die Konfiguration anpassen müssen, können sie Ergänzungen unter /usr/ installieren. Dateien
in /etc/ sind für den lokalen Administrator reserviert, der diese Logik verwenden kann, um die durch die
Lieferantenpakete bereitgestellten Konfigurationsdateien außer Kraft zu setzen. Um Ergänzungen der Pakete
außer Kraft zu setzen, müssen Ergänzungen verwandt werden, da die Hauptkonfigurationsdatei die niedrigste
Priorität hat. Es wird empfohlen, allen Dateinamen in diesen Unterverzeichnissen eine zweistellige Zahl
und einen Bindestrich voranzustellen, um die Sortierung zu vereinfachen. Dies definiert auch ein Konzept
von Ergänzungsprioritäten, um es Betriebssystemlieferanten zu ermöglichen, Ergänzungen in einem
bestimmten Bereich auszuliefern, der unterhalb des von Benutzern verwandten Bereichs liegt. Dies sollte
das Risiko reduzieren, dass eine Paketergänzung versehentlich durch Benutzer definierte Ergänzungen außer
Kraft setzt. Es wird empfohlen, den Bereich 10-40 für Ergänzungen in /usr/ und den Bereich 60-90 für
Ergänzungen in /etc/ und /run/ zu verwenden um sicherzustellen, dass lokale und flüchtige Ergänzungen
Priorität gegenüber Ergänzungen haben, die vom Betriebssystemlieferanten geliefert werden.

Um eine vom Lieferanten bereitgestellte Konfigurationsdatei zu deaktivieren, wird empfohlen, einen
Symlink nach /dev/null in dem Konfigurationsverzeichnis in /etc/ mit dem gleichen Dateinamen wie die
Konfigurationsdatei des Lieferanten abzulegen.

OPTIONEN

Alle Optionen werden im Abschnitt »[Journal]« konfiguriert:

Storage=
Steuert, wo Journal-Daten gespeichert werden. Eines aus »volatile«, »persistent«, »auto«, »none«.
Falls »volatile«, werden die Journal-Protokolldaten nur im Arbeitsspeicher gespeichert, d.h.
unterhalb der Hierarchie /run/log/journal (die falls notwendig erstellt wird). Falls »persistent«,
werden die Daten vorzugsweise auf Platte gespeichert, d.h. unterhalb der Hierarchie /var/log/journal
(die falls notwendig erstellt wird), mit der Rückfalloption /run/log/journal (das falls notwendig
erstellt wird) während der frühen Systemstartphase oder falls die Platte nicht schreibbar ist. »auto«
verhält sich wie »persistent«, falls das Verzeichnis /var/log/journal existiert, andernfalls wie
»volatile« (die Existenz des Verzeichnisses steuert den Speichermodus). »none« schaltet sämtliche
Speicherung aus, alle empfangenen Protokolldaten werden verworfen (aber Weiterleitung an andere
Ziele, wie die Konsole, den Kernel-Protokollpuffer oder ein Syslog-Socket werden weiterhin
funktionieren). Standardmäßig »auto« im Vorgabe-Journal-Namensraum und »persistent« in allen anderen.

Beachten Sie, dass Journald anfänglich flüchtigen Speicher verwenden wird, bis ein Aufruf von
journalctl --flush (oder das Senden von SIGUSR1 an Journald) dazu führt, dass er zum Protokollieren
auf dauerhaften Speicher umschaltet (unter den oben erwähnten Bedingungen). Dies erfolgt beim
Systemstart automatisch mittels »systemd-journal-flush.service«.

Beachten Sie, dass bestehende Daten nicht entfernt werden, wenn diese Option auf »volatile« geändert
wird. In die andere Richtung kann journalctl(1) mit der Option --flush verwandt werden, um flüchtige
Daten auf dauerhafte Speichermedien zu verschieben.

Wenn Namensräume für Journale (siehe LogNamespace= in systemd.exec(5)) verwandt werden, wird das
Setzen von Storage= auf »volatile« oder »auto« keine Auswirkungen auf die Erstellung der
namensraumbezogenen Protokollverzeichnisse in /var/log/journal/ haben, da die Datei
systemd-journald@.service service standardmäßig LogsDirectory= trägt. Um dies abzuschalten, fügen Sie
eine Unit in einer Ergänzungsdatei hinzu, die LogsDirectory= auf eine leere Zeichenkette setzt.

Beachten Sie, dass benutzerbezogene Journal-Dateien nur unterstützt werden, wenn dauerhafte
Speicherung aktiviert ist, wodurch journalctl --user nicht verfügbar ist.

Der zu verwendende Speicher kann auch mittels der Zugangsberechtigung »journal.storage« festgelegt
werden. Werte, die über Konfigurationsdateien konfiguriert werden, haben gegenüber Werten aus der
Zugangsberechtigung Vorrang.

Hinzugefügt in Version 186.

Compress=
Kann einen logischen Wert akzeptieren. Falls aktiviert (die Vorgabe), werden Datenobjekte, die in das
Journal gespeichert werden sollen, vor dem Schreiben in das Dateisystem komprimiert, falls sie größer
als die Standard-Schwelle von 512 Byte sind. Sie kann auch auf eine Anzahl von Bytes gesetzt werden,
die die Komprimierungsschwelle direkt angibt. Zur Angabe größerer Einheiten können Buchstaben der
Form K, M und G angehängt werden.

Seal=
Akzeptiert einen logischen Wert. Falls aktiviert (die Vorgabe) und ein Versiegelungsschlüssel
verfügbar ist (wie vom Befehl --setup-keys von journalctl(1) erstellt), wird »Forward Secure Sealing
(FSS)« für alle dauerhaften Journal-Dateien aktiviert. FSS basiert auf Durchsuchbare sequenzielle
Schlüsselgeneratoren[2] von G. A. Marson und B. Poettering (doi:10.1007/978-3-642-40203-6_7) und kann
zum Schutz der Journal-Dateien vor unbemerkten Änderungen verwandt werden.

Hinzugefügt in Version 189.

SplitMode=
Steuert, ob Journal-Dateien pro Benutzer aufgespalten werden sollen, entweder »uid« oder »none«.
Aufgeteilte Journal-Dateien sind primär für die Zugriffssteuerung nützlich: unter UNIX/Linux wird die
Zugriffssteuerung primär pro Datei verwaltet und der Journal-Daemon wird Benutzern Lesezugriff auf
ihre Dateien zuweisen. Falls »uid«, werden alle regulären Benutzer (mit UID außerhalb des Bereichs
der Systembenutzer, dynamischen Dienste-Benutzer und des Benutzers »nobody«) ihre eigene
Journal-Dateien bekommen und Systembenutzer werden in das System-Journal protokollieren. Siehe
Benutzer, Gruppen, UIDs und GIDs auf Systemd-Systemen[3] für weitere Details über UID-Bereiche. Falls
»none«, werden die Journal-Dateien nicht pro Benutzer aufgeteilt und alle Nachrichten werden
stattdessen in ein einzelnes System-Journal gespeichert. In diesem Modus haben unprivilegierte
Benutzer im Allgemeinen keinen Zugriff auf ihre eigenen Protokolldaten. Beachten Sie, dass das
Aufteilen von Journal-Dateien pro Benutzer nur für dauerhafte gespeicherte Journals möglich ist.
Falls Journals auf flüchtigem Speicher abgelegt werden (siehe Storage= oben), wird nur eine einzelne
Journal-Datei benutzt. Standardmäßig »uid«.

Hinzugefügt in Version 190.

RateLimitIntervalSec=, RateLimitBurst=
Konfiguriert die auf alle im System erstellten Nachrichten angewandte Ratenbegrenzung. Falls in dem
in RateLimitIntervalSec= festgelegten Intervall mehr als in RateLimitBurst= festgelegte Nachrichten
durch einen Dienst protokolliert werden, werden alle weiteren Nachrichten in dem Intervall verworfen,
bis das Intervall vorbei ist. Es wird eine Nachricht über die Anzahl der verworfenen Meldungen
erstellt. Diese Ratenbegrenzung wird pro Dienst angewandt, so dass zwei protokollierende Dienste die
jeweils andere Begrenzung nicht stören. Standardmäßig 10000 Nachrichten in 30 s. Die Zeitfestlegung
für RateLimitIntervalSec= kann in den folgenden Einheiten vorgenommen werden: »s«, »min«, »h«, »ms«,
»us«. Um alle Arten von Ratenbegrenzung auszuschalten, setzen Sie einen der Werte auf 0.

Beachten Sie, dass die effektive Ratenbegrenzung mit einem Faktor multipliziert wird, der von dem
freien Plattenplatz für das Journal abgeleitet wird. Derzeit wird der Faktor mit einem Logarithmus
zur Basis 2 berechnet.

Tabelle 1. Beispiel RateLimitBurst= Ratenveränderung durch den verfügbaren Plattenplatz
┌──────────────────────────┬───────────────────────────┐
│ Verfügbarer Plattenplatz │ Signalfolgenmultiplikator │
├──────────────────────────┼───────────────────────────┤
│ <= 1MB │ 1 │
├──────────────────────────┼───────────────────────────┤
│ <= 16MB │ 2 │
├──────────────────────────┼───────────────────────────┤
│ <= 256MB │ 3 │
├──────────────────────────┼───────────────────────────┤
│ <= 4GB │ 4 │
├──────────────────────────┼───────────────────────────┤
│ <= 64GB │ 5 │
├──────────────────────────┼───────────────────────────┤
│ <= 1TB │ 6 │
└──────────────────────────┴───────────────────────────┘

Falls ein Dienst Ratenbegrenzungen für sich selbst mittels LogRateLimitIntervalSec= und/oder
LogRateLimitBurst= in systemd.exec(5) bereitstellt, werden diese Werte die hier festgelegten
Einstellungen außer Kraft setzen.

SystemMaxUse=, SystemKeepFree=, SystemMaxFileSize=, SystemMaxFiles=, RuntimeMaxUse=, RuntimeKeepFree=,
RuntimeMaxFileSize=, RuntimeMaxFiles=
Erzwingt Größenbegrenzungen für die gespeicherten Journal-Dateien. Die Optionen, an deren Anfang
»System« steht, gelten für Journal-Dateien auf einem dauerhaften Dateisystem, genauer
/var/log/journal. Die Optionen, denen »Runtime« vorangestellt ist, gelten für Journal-Dateien, die
auf einem flüchtigen arbeitsspeicherinternen Dateisystem abgelegt sind, genauer /run/log/journal.
Ersteres wird nur verwandt, wenn /var/ eingehängt und schreibbar ist sowie /var/log/journal
existiert. Andernfalls gilt nur Letzteres. Beachten Sie, dass dies bedeutet, dass während der frühen
Systemstartphase und falls der Administrator dauerhafte Protokollierung deaktiviert, nur die späteren
Optionen gelten, während die ersteren gelten, falls dauerhafte Protokollierung aktiviert und das
System voll gestartet ist. journalctl und systemd-journald ignorieren alle Dateien, deren Namen nicht
auf ».journal« oder ».journal~« enden, daher werden nur solche Dateien, die sich in den geeigneten
Verzeichnissen befinden, bei der Berechnung des aktuellen Plattenplatzverbrauchs berücksichtigt.

SystemMaxUse= und RuntimeMaxUse= steuern, wieviel Plattenplatz das Journal maximal verwenden darf.
SystemKeepFree= und RuntimeKeepFree= steuern, wieviel Plattenplatz Systemd-journald für andere
Verwendungen frei lassen soll. systemd-journald wird beide Begrenzungen respektieren und den
kleineren der beiden Werte verwenden.

Das erste Paar ist standardmäßig 10% und das zweite 15% der Größe des entsprechenden Dateisystems,
aber jeder Wert ist auf 4 G begrenzt. Falls das Dateisystem fast voll ist und entweder
SystemKeepFree= oder RuntimeKeepFree= überschritten sind, wenn Systemd-journald gestartet wird, wird
die Grenze auf den Prozentwert, der tatsächlich frei ist, erhöht. Das bedeutet, falls vorher genug
freier Platz war und die Journal-Dateien erstellt wurden und nachfolgend etwas anderes dazu führte,
dass sich das Dateisystem auffüllte, Journald aufhört, mehr Platz zu verwenden, es aber auch nicht
existierende Dateien entfernen wird, um den Platzverbrauch wieder zu verkleinern. Beachten Sie auch,
dass nur archivierte Dateien zur Verringerung des durch Journal-Dateien benötigten Platzes gelöscht
werden. Das bedeutet, dass nach Abschluss der Bereinigungsaktion tatsächlich mehr Platz verwandt sein
könnte, als in SystemMaxUse= oder RuntimeMaxUse= als Begrenzung angegeben ist.

SystemMaxFileSize= und RuntimeMaxFileSize= steuern, wie groß einzelne Journal-Dateien maximal
anwachsen dürfen. Dies beeinflusst die Granularität, in der Plattenplatz mittels Rotation zur
Verfügung gestellt wird, d.h. die Löschung historischer Daten. Standardmäßig ein Achtel des mit
SystemMaxUse= und RuntimeMaxUse= konfigurierten Wertes (gedeckelt auf 128 MB), so dass normalerweise
sieben rotierte Journal-Dateien als historisch behalten werden. Falls der Journal-Kompaktmodus
aktiviert ist (standardmäßig aktiviert), wird die maximale Dateigröße auf 4 GB begrenzt.

Geben Sie Werte in Byte an oder verwenden Sie K, M, G, T, P, E als Einheiten für die angegebenen
Größen (gleich 1024, 1024², … Byte). Beachten Sie, dass Größenbegrenzungen synchron erzwungen werden,
wenn Journal-Dateien erweitert werden und es nicht notwendig ist, explizit zeitgesteuerte Rotationen
auszulösen.

SystemMaxFiles= und RuntimeMaxFiles= steuern, wie viele einzelne Journal-Dateien maximal zu behalten
sind. Beachten Sie, dass nur archivierte Dateien gelöscht werden, um die Anzahl der Dateien zu
reduzieren, bis diese Begrenzung erreicht ist; aktive Dateien bleiben erhalten. Das bedeutet, dass
effektiv insgesamt mehr Dateien nach der Bereinigungsaktion verbleiben könnten, als diese Begrenzung
erlaubt.

MaxFileSec=
Die maximale Zeit, die Einträge in einer einzelnen Journal-Datei gespeichert werden, bevor auf die
nächste rotiert wird. Normalerweise sollte eine zeitbasierte Rotation nicht notwendig sein, da
Optionen wie SystemMaxFileSize= ausreichend sein sollten, um zu verhindern, dass Journal-Dateien ohne
Grenzen wachsen. Um allerdings sicherzustellen, dass nicht zu viel Daten auf einmal verloren sind,
wenn alte Journal-Dateien gelöscht werden, könnte es Sinn ergeben, diesen Wert von der Vorgabe (ein
Monat) zu verändern. Setzen Sie sie auf 0, um diese Funktionalität auszuschalten. Diese Einstellung
akzeptiert Zeitwerte, denen die Einheiten »year«, »month«, »week«, »day↔, »h« oder »m« angehängt
werden können, um die Vorgabezeiteinheit (Sekunden) außer Kraft zu setzen.

Hinzugefügt in Version 195.

MaxRetentionSec=
Die maximale Zeit, die Journal-Einträge gespeichert werden sollen. Dies steuert, ob Journal-Dateien,
die Einträge älter als die festgelegte Zeitdauer enthalten, gelöscht werden. Normalerweise sollte
zeitbasiertes Löschen von Journal-Dateien nicht erforderlich sein, da größenbasiertes Löschen mit
Optionen wie SystemMaxUse= ausreichend sein sollte, um sicherzustellen, dass Journal-Dateien
grenzenlos wachsen. Um allerdings Datenspeicherungsrichtlinien durchzusetzen, könnte es Sinn ergeben,
diesen Wert von der Vorgabe 0 (die diese Funktionalität ausschaltet) zu ändern. Diese Einstellung
akzeptiert auch Zeitwerte, denen eine Einheit »year«, »month«, »week«, »day«, »h« oder » m« angehängt
werden kann, um die Vorgabezeiteinheit Sekunden außer Kraft zu setzen.

Hinzugefügt in Version 195.

SyncIntervalSec=
Die Zeitüberschreitung, bevor Journal-Dateien auf Platte synchronisiert werden. Nach der
Synchronisation werden die Journal-Dateien in den Zustand OFFLINE gestellt. Beachten Sie, dass die
Synchronisierung bedingungslos sofort erfolgt, nachdem eine Nachricht mit der Priorität CRIT, ALERT
oder EMERG protokolliert wurde. Daher gilt diese Einstellung nur für Nachrichten der Stufen ERR,
WARNING, NOTICE, INFO, DEBUG. Die Vorgabezeitüberschreitung ist 5 Minuten.

Hinzugefügt in Version 199.

ForwardToSyslog=, ForwardToKMsg=, ForwardToConsole=, ForwardToWall=, ForwardToSocket=
Steuert, ob durch den Journal-Daemon empfangene Protokollnachrichten an einen traditionellen
Syslog-Daemon, zu dem Kernel-Protokollpuffer (kmesg), der Systemkonsole, als Wall-Nachrichten an alle
angemeldeten Benutzer oder über ein Socket weitergeleitet werden sollen. Diese Optionen akzeptieren
logische Argumente außer »ForwardToSocket«, das stattdessen eine Adresse akzeptiert. Falls die
Weiterleitung an Syslog aktiviert ist, aber nichts die Nachrichten vom Socket liest, hat die
Weiterleitung an Syslog keinen Effekt. Standardmäßig ist nur die Weiterleitung an Wall aktiviert.
Diese Einstellungen können zum Systemstartzeitpunkt mit den Kernelbefehlzeilenoptionen
»systemd.journald.forward_to_syslog«, »systemd.journald.forward_to_kmsg«,
»systemd.journald.forward_to_console« und »systemd.journald.forward_to_wall« außer Kraft gesetzt
werden. Falls der Optionsname ohne »=« und dem nachfolgenden Argument festgelegt ist, wird true
angenommen. Andernfalls wird das Argument als logischer Wert ausgewertet.

Die Socket-Weiterleitungsadresse kann mittels der Zugangsberechtigung »journal.forward_to_socket«
festgelegt werden. Die folgenden Socket-Typen werden unterstützt:

AF_INET (z.B. »192.168.0.11:4444«), AF_INET6 (z.B. »[2001:db8::ff00:42:8329]:4444«), AF_UNIX (z.B.
»/run/host/journal/socket«), AF_VSOCK (z.B. »vsock:2:1234«)

Bei der Weiterleitung an die Konsole kann das TTY, auf das protokolliert wird, mit dem früher
beschriebenen TTYPath= geändert werden.

Stellen Sie beim Weiterleiten des Kernelprotokollpuffers (kmsg) sicher, eine geeignete (große) Größe
für den Protokollpuffer auszuwählen, zum Beispiel indem Sie »log_buf_len=8M« auf der
Kernelbefehlszeile hinzufügen. systemd wird automatisch die auf der Anwendungsebene angewandte
Ratenbegrenzung des Kernels deaktivieren (äquivalent zum Setzen von » printk.devkmsg=on«).

Bei Weiterleiten über ein Socket wird das Journal-Exportformat[4] zum Senden über die Leitung
verwandt. Insbesondere enthält dies das Metadatenfeld __REALTIME_TIMESTAMP, so dass
systemd-journal-remote(8) (siehe systemd-journal-remote.service(8)) dazu verwandt werden kann, die
weitergeleiteten Journal-Einträge zu empfangen.

Hinweis: Weiterleitung erfolgt innerhalb von Journald synchron und kann seine Leistung signifikant
beeinflussen. Dies ist insbesondere relevant, wenn in Cloud-Umgebungen »ForwardToConsole=yes«
verwandt wird, wo die Konsole oft ein langsamer, virtueller, serieller Port ist. Da Journald als
konventioneller Daemon in einem Prozess implementiert ist, wird das Weiterleiten an eine aufgehängte
Konsole Journald blockieren. Dies kann einen kaskadierenden Effekt haben, der dazu führt, dass alle
an das blockierte Journal synchron protokollierende Dienste auch blockiert werden. Außer bei der
aktiven Fehlersuche oder Entwicklung von irgendetwas, wird im Allgemeinen für den Produktiveinsatz
empfohlen, anstelle von »ForwardToConsole=yes« einen Dienst der Art journalctl --follow einzurichten,
der auf eine Konsole umgeleitet wird.

Hinweis: Die Verwendung von ForwardToSocket= über IPv4/IPv6-Links kann aufgrund der synchronen Natur
der Sockets sehr langsam sein. Stellen Sie sicher, dass Ihr Link über möglichst niedrige Latenz
verfügt, wenn möglich. Typischerweise ist nicht überall, wo Journald läuft, IP-Vernetzung verfügbar,
z.B. in der Initrd während des Systemstarts. Ziehen Sie dafür die Verwendung von
AF_VSOCK/AF_UNIX-Sockets in Betracht, wenn möglich.

MaxLevelStore=, MaxLevelSyslog=, MaxLevelKMsg=, MaxLevelConsole=, MaxLevelWall=, MaxLevelSocket=
Steuert die maximale Protokollierstufe für Nachrichten, die im Journal gespeichert, an Syslog, Kmesg,
die Konsole, Wall oder einem Socket weitergeleitet (falls dies aktiviert ist, siehe oben) werden.
Akzeptiert als Argument eines aus »emerg«, »alert«, »crit«, »err«, »warning«, »notice«, »info«,
»debug« oder Ganzzahlwerte im Bereich 0…7 (entsprechend der selben Stufen). Nachrichten identisch mit
oder unterhalb der festgelegten Protokollierstufe werden gespeichert/weitergeleitet, Nachrichten
oberhalb werden verworfen. Standardmäßig »debug« für MaxLevelStore=, MaxLevelSyslog= und
MaxLevelSocket=, um sicherzustellen, dass alle Nachrichten im Journal gespeichert, an Syslog und das
Socket, falls es existiert, weitergeleitet werden. Standardmäßig »notice« für MaxLevelKMsg=, »info«
für MaxLevelConsole= und »emerg« für MaxLevelWall=. Diese Einstellungen können zum
Systemstartzeitpunkt mit den Kernelbefehlszeilenoptionen »systemd.journald.max_level_store=«,
»systemd.journald.max_level_syslog=«, »systemd.journald.max_level_kmsg=«,
»systemd.journald.max_level_console=«, »systemd.journald.max_level_wall=«,
»systemd.journald.max_level_socket=« außer Kraft gesetzt werden.

Hinzugefügt in Version 185.

ReadKMsg=
Akzeptiert einen logischen Wert. Falls aktiviert, verarbeitet systemd-journal die vom Kernel
erstellten /dev/kmsg-Nachrichten. Im Vorgabe-Namensraum ist diese Option standardmäßig aktiviert. In
allen anderen Namensräumen ist sie deaktiviert.

Hinzugefügt in Version 235.

Audit=
Akzeptiert einen logischen Wert. Falls aktiviert, wird systemd-journal beim Starten die
Kernel-Auditierung einschalten. Falls deaktiviert, wird sie diese ausschalten. Falls nicht gesetzt,
wird sie diese weder aktivieren noch deaktivieren, sondern den vorherigen Zustand unverändert lassen.
Das bedeutet, dass systemd-journald sie weiterhin sammeln wird, wenn zwar systemd-journald die
Erzeugung ausgestellt, ein anderes Werkzeug sie aber angestellt hat. Standardmäßig ein.

Beachten Sie, dass diese Option nicht steuert, ob systemd-journald die erstellten Audit-Datensätze
sammelt, sie steuert nur, ob der Kernel um die Erzeugung gebeten wird. Falls Sie verhindern müssen,
dass systemd-journald die erstellten Meldungen sammelt, kann die Socket-Unit
»systemd-journald-audit.socket« deaktiviert werden. In diesem Fall hat diese Einstellung keine
Auswirkungen.

Hinzugefügt in Version 246.

TTYPath=
Ändert das zu verwendende Konsole-TTY, falls ForwardToConsole=yes verwendet wird. Standardmäßig
/dev/console.

Hinzugefügt in Version 185.

LineMax=
Die maximale zu erlaubende Länge bei der Umwandlung von Datenstromprotokollen in Datensatzprotokolle.
Wenn die Standardausgabe/der Standardfehler einer Systemd-Unit über ein Datenstrom-Socket mit dem
Journal verbunden ist, werden die gelesenen Daten in einzelne Datensätze bei dem Zeilenumbruch (»\n«,
ASCII 10) und beim Nullbyte-Zeichen (NUL) aufgeteilt. Falls für die festgelegte Anzahl an Byte kein
solcher Begrenzer gelesen wird, wird eine harte Datensatzgrenze künstlich eingefügt, die damit
überlange Zeilen in mehrere Protokolldatensätze aufteilt. Durch Auswahl sehr großer Werte wird der
mögliche Speicherverbrauch des Journal-Daemons für jeden Datenstrom-Client erhöht, da im schlimmsten
Falle der Journal-Daemon die festgelegte Anzahl von Byte im Speicher puffern muss, bevor er neue
Protokolldatensätze auf die Platte rausschreiben kann. Beachten Sie auch, dass das Erlauben sehr
großer maximaler Zeilenlängen die Kompatibilität mit traditionellen Protokollen betrifft, da
Protokolldatensätze nicht mehr in ein einzelnes AF_UNIX- oder AF_INET-Datagramm passen könnten.
Akzeptiert eine Größe in Byte. Falls dem Wert K, M, G oder T angehängt wird, wird die angegebene
Größe als Kilobyte, Megabyte, Gigabyte bzw. Terabyte (zur Basis 1024) ausgewertet. Standardmäßig 49
K, was relativ groß aber immer noch klein genug ist, so dass Protokolldatensätze wahrscheinlich in
Netz-Datagramme zusammen mit Extraraum für Metadaten passen. Beachten Sie, dass Werte kleiner als 79
nicht akzeptiert und auf 79 erhöht werden.

Hinzugefügt in Version 235.

WEITERLEITUNG AN TRADITIONELLE SYSLOG-DAEMONS

       Journal-Ereignisse können an andere Protokollier-Daemons auf zwei verschiedene Arten übertragen werden.
       Mit der ersten Methode werden Nachrichten sofort an ein Socket (/run/systemd/journal/syslog)
       weitergeleitet, an der der traditionelle Syslog-Daemon sie lesen kann. Diese Methode wird durch die
       Option ForwardToSyslog= gesteuert. Mit der zweiten Methode verhält sich ein Syslog-Demon wie ein normaler
       Journal-Client und liest Nachrichten aus den Journal-Dateien, ähnlich journalctl(1). Damit müssen
       Nachrichten nicht sofort gelesen werden, womit ein Protokollier-Daemon ermöglicht wird, der erst spät im
       Systemstartprozess gestartet wird und dann auf alle Nachrichten seit dem Start des Systems zugreifen
       kann. Zusätzlich sind ihm komplett-strukturierte Metadaten zugänglich. Diese Methode ist natürlich nur
       verfügbar, falls die Nachrichten überhaupt in einer Journal-Datei gespeichert werden. Daher wird sie
       nicht funktionieren, falls Storage=none gesetzt ist. Es sollte angemerkt werden, dass normalerweise die
       zweite Methode von Syslog-Daemons verwandt wird und daher die Option Storage=, und nicht die Option
       ForwardToSyslog= relevant ist.

SIEHE AUCH

       systemd(1), systemd-journald.service(8), journalctl(1), systemd.journal-fields(7), systemd-system.conf(5)

ANMERKUNGEN

        1. 💣💥🧨💥💥💣  Bitte  beachten  Sie,  dass  diese Konfigurationsdateien zu allen Zeiten verfügbar sein
           müssen. Falls /usr/local/ eine separate Partition ist, könnte diese während des  frühen  Systemstarts
           nicht verfügbar sein und darf dann nicht für Konfiguration verwandt werden.

        2. Durchsuchbare sequenzielle Schlüsselgeneratoren
           https://eprint.iacr.org/2013/397

        3. Benutzer, Gruppen, UIDs und GIDs auf Systemd-Systemen
           https://systemd.io/UIDS-GIDS

        4. Journal-Exportformat
           https://systemd.io/JOURNAL_EXPORT_FORMATS/#journal-export-format

ÜBERSETZUNG

       Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann <debian@helgefjell.de> erstellt.

       Diese  Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer
       bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen.

       Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte  eine  E-Mail  an  die
       Mailingliste der Übersetzer.

systemd 257.3                                                                                   JOURNALD.CONF(5)