Provided by: manpages-de_2.16-1_all 
BEZEICHNUNG
journald.conf, journald.conf.d - 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
BESCHREIBUNG
Diese Dateien konfigurieren verschiedene Parameter des Systemd-Journal-Dienstes
systemd-journald.service(8). Siehe systemd.syntax(5) für eine allgemeine Beschreibung der Syntax.
KONFIGURATIONSVERZEICHNISSE UND RANGFOLGE
Die Standardkonfiguration wird während der Kompilierung definiert. Daher wird eine Konfigurationsdatei
nur benötigt, wenn von diesen Vorgaben abgewichen werden muss. Standardmäßig enthält die
Konfigurationsdatei in /etc/systemd/ die Vorgaben als auskommentierten Hinweis für den Administrator.
Diese Datei kann bearbeitet werden, um lokal Einstellungen zu ändern.
Wenn Pakete die Konfiguration anpassen müssen, können sie Konfigurationsschnipsel in
/usr/lib/systemd/*.conf.d/ oder /usr/local/lib/systemd/*.conf.d/installieren. Dateien in /etc/ sind für
den lokalen Administrator reserviert, der diese Logik dazu verwenden kann, die von Lieferantenpaketen
installierten Konfigurationsdateien außer Kraft zu setzen. Die Hauptkonfigurationsdatei wird vor jeder
anderen aus den Konfigurationsverzeichnissen gelesen und hat die niedrigste Priorität; Einträge in einer
Datei in jedem der Konfigurationsverzeichnisse setzen Einträge in der einzelnen Konfigurationsdatei 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 mit dem lexikographisch
letzten Namen Vorrang, falls mehrere Dateien die gleiche Option festlegen. Bei Optionen, die eine Liste
von Werten akzeptieren, werden Einträge zusammengefasst, wie sie in den lexikographisch sortierten
Dateien auftauchen. Es wird empfohlen, allen Dateinamen in diesen Unterverzeichnissen eine zweistellige
Zahl und einen Gedankenstrich voranzustellen, um die Anordnung der Dateien zu vereinfachen.
Um eine vom Lieferanten bereitgestellte Konfigurationsdatei zu deaktivieren, wird empfohlen, einen
Symlink nach /dev/null in dem Konfigurationsverzeichnis /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«
ist ähnlich »persistent«, aber das Verzeichnis /var/log/journal wird nicht erstellt, falls benötigt,
so das dessen Existenz steuert, wohin Protokolldaten gelangen. »none« schaltet sämtliche Speicherung
aus, alle empfangenen Protokolldaten werden verworfen. Weiterleitung an andere Ziele, wie die
Konsole, den Kernel-Protokollpuffer oder ein Syslog-Socket werden allerdings weiterhin funktionieren.
Standardmäßig »auto«.
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 festlegt. 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.
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 Benutzer ihre eigene Journal-Dateien bekommen und
Systembenutzer werden in das System-Journal protokollieren. 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«.
RateLimitIntervalSec=, RateLimitBurst=
Konfiguriert die auf alle im System erstellten Nachrichten angewandte Ratenbegrenzung. Falls im 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.
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, so dass normalerweise sieben rotierte
Journal-Dateien als historisch behalten werden.
Legen Sie Werte in Bytes fest oder verwenden Sie K, M, G, T, P, E als Einheiten für die festgelegten
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.
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.
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.
ForwardToSyslog=, ForwardToKMsg=, ForwardToConsole=, ForwardToWall=
Steuert, ob durch den Journal-Daemon empfangene Protokollnachrichten an einen traditionellen
Syslog-Daemon, zu dem Kernel-Protokollpuffer (kmesg), der Systemkonsole oder als Wall-Nachrichten an
alle angemeldeten Benutzer weitergeleitet werden sollen. Diese Optionen akzeptieren logische
Argumente. 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
Syslog und 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.
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 und dass die Kernel-Ratenbegrenzung, die auf Prozesse im
Anwendungsraum angewandt wird, ausgeschaltet ist. Fügen Sie insbesondere »log_buf_len=8M« und
»printk.devkmsg=on« (oder ähnliches) zu der Befehlszeile des Kernels hinzu.
MaxLevelStore=, MaxLevelSyslog=, MaxLevelKMsg=, MaxLevelConsole=, MaxLevelWall=
Steuert die maximale Protokollierstufe für Nachrichten, die auf Platte gespeichert, an Syslog, Kmesg,
die Konsole oder Wall 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= und MaxLevelSyslog=, um sicherzustellen,
dass alle Nachrichten auf Platte geschrieben und an Syslog 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=« außer Kraft gesetzt werden.
ReadKMsg=
Akzeptiert einen logischen Wert. Falls aktiviert (die Vorgabe), liest Journal die vom Kernel
erstellten /dev/kmsg-Nachrichten.
TTYPath=
Ändert das zu verwendende Konsole-TTY, falls ForwardToConsole=yes verwendet wird. Standardmäßig
/dev/console.
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 NUL-Zeichen aufgeteilt. Falls für die festgelegte Anzahl an Bytes 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 Bytes 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 festgelegte
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.
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
Ü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 <debian-l10n-german@lists.debian.org>.