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/lib/systemd/journald.conf
           /etc/systemd/journald.conf.d/*.conf
           /run/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/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/, /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 der Dateien 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[1] 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[2] 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 wahr 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[3] 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. Durchsuchbare sequenzielle Schlüsselgeneratoren
           https://eprint.iacr.org/2013/397

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

        3. 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 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ 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 ⟨debian-l10n-german@lists.debian.org⟩.