- bookworm 4.18.1-1
- bookworm-backports 4.24.0-2~bpo12+1
- testing 4.24.0-2
- unstable 4.24.0-2
JOURNALD.CONF(5) | journald.conf | JOURNALD.CONF(5) |
BEZEICHNUNG¶
journald.conf, journald.conf.d, journald@.conf - Journal-Dienst-Konfigurationsdateien
ÜBERSICHT¶
/etc/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. Anfänglich enthält die Hauptkonfigurationsdatei in /etc/systemd/ die Vorgaben als auskommentierten Hinweis für den Administrator. Lokal können diese Einstellungen außer Kraft gesetzt werden, indem diese Datei bearbeitet wird oder durch die Erstellung von Ergänzungen, wie nachfolgend beschrieben. Es wird empfohlen, Ergänzungen für lokale Konfiguration zu verwenden, statt die Hauptkonfigurationsdatei zu verändern.
Zusätzlich zu der »Haupt«-Konfigurationsdatei, 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.
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=
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.
Compress=
Seal=
SplitMode=
RateLimitIntervalSec=, RateLimitBurst=
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=
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, so dass normalerweise sieben rotierte Journal-Dateien als historisch behalten werden.
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=
MaxRetentionSec=
SyncIntervalSec=
ForwardToSyslog=, ForwardToKMsg=, ForwardToConsole=, ForwardToWall=
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«).
MaxLevelStore=, MaxLevelSyslog=, MaxLevelKMsg=, MaxLevelConsole=, MaxLevelWall=
ReadKMsg=
Audit=
TTYPath=
LineMax=
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
- 2.
- Benutzer, Gruppen, UIDs und GIDs auf Systemd-Systemen
Ü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 251 |