Provided by: manpages-de_2.15-1build1_all bug

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/ 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.

       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>.