JOURNALD.CONF(5) journald.conf JOURNALD.CONF(5) BEZEICHNUNG journald.conf, journald.conf.d, journald@.conf - Journal-Dienst-Konfigurationsdateien UBERSICHT /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) fur eine allgemeine Beschreibung der Syntax. Die systemd-journald-Instanz, die den Vorgabe-Namensraum verwaltet, wird in /etc/systemd/journald.conf und zugeordneten Erganzungen konfiguriert. Instanzen, die andere Namensraume verwalten, lesen /etc/systemd/journald@NAMENSRAUM.conf und zugeordnete Erganzungen, wobei der Namensraumkennzeichner eingefullt wird. Dies ermoglicht es jedem Namensraum, eine eigenstandige Konfiguration zu transportieren. Lesen Sie systemd-journald.service(8) fur Details uber Journal-Namensraume. KONFIGURATIONSVERZEICHNISSE UND RANGFOLGE Die Standardkonfiguration wird wahrend der Kompilierung gesetzt. Daher wird eine Konfiguration nur benotigt, wenn von diesen Vorgaben abgewichen werden muss. Die Hauptkonfigurationsdatei ist entweder /usr/lib/systemd/ oder /etc/systemd/ und enthalt die Vorgaben als auskommentierte Hinweise fur den Administrator. Lokal konnen diese Einstellungen durch die Erstellung von Erganzungen, wie nachfolgend beschrieben, ausser 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, Erganzungen fur lokale Konfiguration zu verwenden, statt die Hauptkonfigurationsdatei zu verandern. Zusatzlich zu der >>Haupt<<-Konfigurationsdatei, werden Erganzungs-Konfigurationsschnipsel aus /usr/lib/systemd/*.conf.d/, /usr/local/lib/systemd/*.conf.d/ und /etc/systemd/*.conf.d/ gelesen. Diese Erganzungen haben Vorrang vor der Hauptkonfigurationsdatei und setzen diese ausser Kraft. Dateien in den Konfigurationsunterverzeichnissen *.conf.d/ werden in lexikographischer Reihenfolge nach ihrem Dateinamen sortiert, unabhangig 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 Eintrage gesammelt, wie sie in den sortierten Dateien auftauchen. Wenn Pakete die Konfiguration anpassen mussen, konnen sie Erganzungen unter /usr/ installieren. Dateien in /etc/ sind fur den lokalen Administrator reserviert, der diese Logik verwenden kann, um die durch die Lieferantenpakete bereitgestellten Konfigurationsdateien ausser Kraft zu setzen. Um Erganzungen der Pakete ausser Kraft zu setzen, mussen Erganzungen verwandt werden, da die Hauptkonfigurationsdatei die niedrigste Prioritat 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 Erganzungsprioritaten, um es Distributionen zu ermoglichen, Erganzungen in einem bestimmten Bereich auszuliefern, der unterhalb des von Benutzern verwandten Bereichs liegt. Dies sollte das Risiko reduzieren, dass eine Paketerganzung versehentlich durch Benutzer definierte Erganzungen ausser Kraft setzt. 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 Ruckfalloption /run/log/journal (das falls notwendig erstellt wird) wahrend der fruhen Systemstartphase oder falls die Platte nicht schreibbar ist. >>auto<< verhalt sich wie >>persistent<<, falls das Verzeichnis /var/log/journal existiert, andernfalls wie >>volatile<< (die Existenz des Verzeichnisses steuert den Speichermodus). >>none<< schaltet samtliche 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). Standardmassig >>auto<< im Vorgabe-Journal-Namensraum und >>persistent<< in allen anderen. Beachten Sie, dass Journald anfanglich fluchtigen Speicher verwenden wird, bis ein Aufruf von journalctl --flush (oder das Senden von SIGUSR1 an Journald) dazu fuhrt, dass er zum Protokollieren auf dauerhaften Speicher umschaltet (unter den oben erwahnten Bedingungen). Dies erfolgt beim Systemstart automatisch mittels >>systemd-journal-flush.service<<. Beachten Sie, dass bestehende Daten nicht entfernt werden, wenn diese Option auf >>volatile<< geandert wird. In die andere Richtung kann journalctl(1) mit der Option --flush verwandt werden, um fluchtige Daten auf dauerhafte Speichermedien zu verschieben. Wenn Namensraume fur 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 standardmassig LogsDirectory= tragt. Um dies abzuschalten, fugen Sie eine Unit in einer Erganzungsdatei hinzu, die LogsDirectory= auf eine leere Zeichenkette setzt. Beachten Sie, dass benutzerbezogene Journal-Dateien nur unterstutzt werden, wenn dauerhafte Speicherung aktiviert ist, wodurch journalctl --user nicht verfugbar ist. Hinzugefugt 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 grosser 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 grosserer Einheiten konnen Buchstaben der Form K, M und G angehangt werden. Seal= Akzeptiert einen logischen Wert. Falls aktiviert (die Vorgabe) und ein Versiegelungsschlussel verfugbar ist (wie vom Befehl --setup-keys von journalctl(1) erstellt), wird >>Forward Secure Sealing (FSS)<< fur alle dauerhaften Journal-Dateien aktiviert. FSS basiert auf Durchsuchbare sequenzielle Schlusselgeneratoren[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 Anderungen verwandt werden. Hinzugefugt in Version 189. SplitMode= Steuert, ob Journal-Dateien pro Benutzer aufgespalten werden sollen, entweder >>uid<< oder >>none<<. Aufgeteilte Journal-Dateien sind primar fur die Zugriffssteuerung nutzlich: unter UNIX/Linux wird die Zugriffssteuerung primar pro Datei verwaltet und der Journal-Daemon wird Benutzern Lesezugriff auf ihre Dateien zuweisen. Falls >>uid<<, werden alle regularen Benutzer (mit UID ausserhalb 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] fur weitere Details uber 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 fur dauerhafte gespeicherte Journals moglich ist. Falls Journals auf fluchtigem Speicher abgelegt werden (siehe Storage= oben), wird nur eine einzelne Journal-Datei benutzt. Standardmassig >>uid<<. Hinzugefugt 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 uber die Anzahl der verworfenen Meldungen erstellt. Diese Ratenbegrenzung wird pro Dienst angewandt, so dass zwei protokollierende Dienste die jeweils andere Begrenzung nicht storen. Standardmassig 10000 Nachrichten in 30 s. Die Zeitfestlegung fur 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 fur das Journal abgeleitet wird. Derzeit wird der Faktor mit einem Logarithmus zur Basis 2 berechnet. Tabelle 1. Beispiel RateLimitBurst= Ratenveranderung durch den verfugbaren Plattenplatz +---------------------------+---------------------------+ |Verfugbarer Plattenplatz | Signalfolgenmultiplikator | +---------------------------+---------------------------+ |<= 1MB | 1 | +---------------------------+---------------------------+ |<= 16MB | 2 | +---------------------------+---------------------------+ |<= 256MB | 3 | +---------------------------+---------------------------+ |<= 4GB | 4 | +---------------------------+---------------------------+ |<= 64GB | 5 | +---------------------------+---------------------------+ |<= 1TB | 6 | +---------------------------+---------------------------+ Falls ein Dienst Ratenbegrenzungen fur sich selbst mittels LogRateLimitIntervalSec= und/oder LogRateLimitBurst= in systemd.exec(5) bereitstellt, werden diese Werte die hier festgelegten Einstellungen ausser Kraft setzen. SystemMaxUse=, SystemKeepFree=, SystemMaxFileSize=, SystemMaxFiles=, RuntimeMaxUse=, RuntimeKeepFree=, RuntimeMaxFileSize=, RuntimeMaxFiles= Erzwingt Grossenbegrenzungen fur die gespeicherten Journal-Dateien. Die Optionen, an deren Anfang >>System<< steht, gelten fur Journal-Dateien auf einem dauerhaften Dateisystem, genauer /var/log/journal. Die Optionen, denen >>Runtime<< vorangestellt ist, gelten fur Journal-Dateien, die auf einem fluchtigen arbeitsspeicherinternen Dateisystem abgelegt sind, genauer /run/log/journal. Ersteres wird nur verwandt, wenn /var/ eingehangt und schreibbar ist sowie /var/log/journal existiert. Andernfalls gilt nur Letzteres. Beachten Sie, dass dies bedeutet, dass wahrend der fruhen Systemstartphase und falls der Administrator dauerhafte Protokollierung deaktiviert, nur die spateren Optionen gelten, wahrend 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 berucksichtigt. SystemMaxUse= und RuntimeMaxUse= steuern, wieviel Plattenplatz das Journal maximal verwenden darf. SystemKeepFree= und RuntimeKeepFree= steuern, wieviel Plattenplatz Systemd-journald fur andere Verwendungen frei lassen soll. systemd-journald wird beide Begrenzungen respektieren und den kleineren der beiden Werte verwenden. Das erste Paar ist standardmassig 10% und das zweite 15% der Grosse des entsprechenden Dateisystems, aber jeder Wert ist auf 4 G begrenzt. Falls das Dateisystem fast voll ist und entweder SystemKeepFree= oder RuntimeKeepFree= uberschritten sind, wenn Systemd-journald gestartet wird, wird die Grenze auf den Prozentwert, der tatsachlich frei ist, erhoht. Das bedeutet, falls vorher genug freier Platz war und die Journal-Dateien erstellt wurden und nachfolgend etwas anderes dazu fuhrte, dass sich das Dateisystem auffullte, Journald aufhort, 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 benotigten Platzes geloscht werden. Das bedeutet, dass nach Abschluss der Bereinigungsaktion tatsachlich mehr Platz verwandt sein konnte, als in SystemMaxUse= oder RuntimeMaxUse= als Begrenzung angegeben ist. SystemMaxFileSize= und RuntimeMaxFileSize= steuern, wie gross einzelne Journal-Dateien maximal anwachsen durfen. Dies beeinflusst die Granularitat, in der Plattenplatz mittels Rotation zur Verfugung gestellt wird, d.h. die Loschung historischer Daten. Standardmassig 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 (standardmassig aktiviert), wird die maximale Dateigrosse auf 4 GB begrenzt. Geben Sie Werte in Byte an oder verwenden Sie K, M, G, T, P, E als Einheiten fur die angegebenen Grossen (gleich 1024, 1024^2, Byte). Beachten Sie, dass Grossenbegrenzungen synchron erzwungen werden, wenn Journal-Dateien erweitert werden und es nicht notwendig ist, explizit zeitgesteuerte Rotationen auszulosen. SystemMaxFiles= und RuntimeMaxFiles= steuern, wie viele einzelne Journal-Dateien maximal zu behalten sind. Beachten Sie, dass nur archivierte Dateien geloscht 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 konnten, als diese Begrenzung erlaubt. MaxFileSec= Die maximale Zeit, die Eintrage in einer einzelnen Journal-Datei gespeichert werden, bevor auf die nachste 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 geloscht werden, konnte es Sinn ergeben, diesen Wert von der Vorgabe (ein Monat) zu verandern. Setzen Sie sie auf 0, um diese Funktionalitat auszuschalten. Diese Einstellung akzeptiert Zeitwerte, denen die Einheiten >>year<<, >>month<<, >>week<<, >>day<->, >>h<< oder >>m<< angehangt werden konnen, um die Vorgabezeiteinheit (Sekunden) ausser Kraft zu setzen. Hinzugefugt in Version 195. MaxRetentionSec= Die maximale Zeit, die Journal-Eintrage gespeichert werden sollen. Dies steuert, ob Journal-Dateien, die Eintrage alter als die festgelegte Zeitdauer enthalten, geloscht werden. Normalerweise sollte zeitbasiertes Loschen von Journal-Dateien nicht erforderlich sein, da grossenbasiertes Loschen mit Optionen wie SystemMaxUse= ausreichend sein sollte, um sicherzustellen, dass Journal-Dateien grenzenlos wachsen. Um allerdings Datenspeicherungsrichtlinien durchzusetzen, konnte es Sinn ergeben, diesen Wert von der Vorgabe 0 (die diese Funktionalitat ausschaltet) zu andern. Diese Einstellung akzeptiert auch Zeitwerte, denen eine Einheit >>year<<, >>month<<, >>week<<, >>day<<, >>h<< oder >> m<< angehangt werden kann, um die Vorgabezeiteinheit Sekunden ausser Kraft zu setzen. Hinzugefugt in Version 195. SyncIntervalSec= Die Zeituberschreitung, 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 Prioritat CRIT, ALERT oder EMERG protokolliert wurde. Daher gilt diese Einstellung nur fur Nachrichten der Stufen ERR, WARNING, NOTICE, INFO, DEBUG. Die Vorgabezeituberschreitung ist 5 Minuten. Hinzugefugt in Version 199. 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. Standardmassig ist nur die Weiterleitung an Wall aktiviert. Diese Einstellungen konnen 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<< ausser 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 fruher beschriebenen TTYPath= geandert werden. Stellen Sie beim Weiterleiten des Kernelprotokollpuffers (kmsg) sicher, eine geeignete (grosse) Grosse fur den Protokollpuffer auszuwahlen, zum Beispiel indem Sie >>log_buf_len=8M<< auf der Kernelbefehlszeile hinzufugen. systemd wird automatisch die auf der Anwendungsebene angewandte Ratenbegrenzung des Kernels deaktivieren (aquivalent zum Setzen von >> printk.devkmsg=on<<). 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 aufgehangte Konsole Journald blockieren. Dies kann einen kaskadierenden Effekt haben, der dazu fuhrt, dass alle an das blockierte Journal synchron protokollierende Dienste auch blockiert werden. Ausser bei der aktiven Fehlersuche oder Entwicklung von irgendetwas, wird im Allgemeinen fur den Produktiveinsatz empfohlen, anstelle von >>ForwardToConsole=yes<< einen Dienst der Art journalctl --follow einzurichten, der auf eine Konsole umgeleitet wird. MaxLevelStore=, MaxLevelSyslog=, MaxLevelKMsg=, MaxLevelConsole=, MaxLevelWall= Steuert die maximale Protokollierstufe fur Nachrichten, die im Journal 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 07 (entsprechend der selben Stufen). Nachrichten identisch mit oder unterhalb der festgelegten Protokollierstufe werden gespeichert/weitergeleitet, Nachrichten oberhalb werden verworfen. Standardmassig >>debug<< fur MaxLevelStore= und MaxLevelSyslog=, um sicherzustellen, dass alle Nachrichten im Journal gespeichert und an Syslog weitergeleitet werden. Standardmassig >>notice<< fur MaxLevelKMsg=, >>info<< fur MaxLevelConsole= und >>emerg<< fur MaxLevelWall=. Diese Einstellungen konnen 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=<< ausser Kraft gesetzt werden. Hinzugefugt 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 standardmassig aktiviert. In allen anderen Namensraumen ist sie deaktiviert. Hinzugefugt 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 unverandert lassen. Das bedeutet, dass systemd-journald sie weiterhin sammeln wird, wenn zwar systemd-journald die Erzeugung ausgestellt, ein anderes Werkzeug sie aber angestellt hat. Standardmassig ein. Beachten Sie, dass diese Option nicht steuert, ob systemd-journald die erstellten Audit-Datensatze sammelt, sie steuert nur, ob der Kernel um die Erzeugung gebeten wird. Falls Sie verhindern mussen, 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. Hinzugefugt in Version 246. TTYPath= Andert das zu verwendende Konsole-TTY, falls ForwardToConsole=yes verwendet wird. Standardmassig /dev/console. Hinzugefugt in Version 185. LineMax= Die maximale zu erlaubende Lange bei der Umwandlung von Datenstromprotokollen in Datensatzprotokolle. Wenn die Standardausgabe/der Standardfehler einer Systemd-Unit uber ein Datenstrom-Socket mit dem Journal verbunden ist, werden die gelesenen Daten in einzelne Datensatze bei dem Zeilenumbruch (>>\n<<, ASCII 10) und beim Nullbyte-Zeichen (NUL) aufgeteilt. Falls fur die festgelegte Anzahl an Byte kein solcher Begrenzer gelesen wird, wird eine harte Datensatzgrenze kunstlich eingefugt, die damit uberlange Zeilen in mehrere Protokolldatensatze aufteilt. Durch Auswahl sehr grosser Werte wird der mogliche Speicherverbrauch des Journal-Daemons fur jeden Datenstrom-Client erhoht, da im schlimmsten Falle der Journal-Daemon die festgelegte Anzahl von Byte im Speicher puffern muss, bevor er neue Protokolldatensatze auf die Platte rausschreiben kann. Beachten Sie auch, dass das Erlauben sehr grosser maximaler Zeilenlangen die Kompatibilitat mit traditionellen Protokollen betrifft, da Protokolldatensatze nicht mehr in ein einzelnes AF_UNIX- oder AF_INET-Datagramm passen konnten. Akzeptiert eine Grosse in Byte. Falls dem Wert K, M, G oder T angehangt wird, wird die angegebene Grosse als Kilobyte, Megabyte, Gigabyte bzw. Terabyte (zur Basis 1024) ausgewertet. Standardmassig 49 K, was relativ gross aber immer noch klein genug ist, so dass Protokolldatensatze wahrscheinlich in Netz-Datagramme zusammen mit Extraraum fur Metadaten passen. Beachten Sie, dass Werte kleiner als 79 nicht akzeptiert und auf 79 erhoht werden. Hinzugefugt in Version 235. WEITERLEITUNG AN TRADITIONELLE SYSLOG-DAEMONS Journal-Ereignisse konnen an andere Protokollier-Daemons auf zwei verschiedene Arten ubertragen 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 verhalt sich ein Syslog-Demon wie ein normaler Journal-Client und liest Nachrichten aus den Journal-Dateien, ahnlich journalctl(1). Damit mussen Nachrichten nicht sofort gelesen werden, womit ein Protokollier-Daemon ermoglicht wird, der erst spat im Systemstartprozess gestartet wird und dann auf alle Nachrichten seit dem Start des Systems zugreifen kann. Zusatzlich sind ihm komplett-strukturierte Metadaten zuganglich. Diese Methode ist naturlich nur verfugbar, falls die Nachrichten uberhaupt 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 Schlusselgeneratoren https://eprint.iacr.org/2013/397 2. Benutzer, Gruppen, UIDs und GIDs auf Systemd-Systemen https://systemd.io/UIDS-GIDS UBERSETZUNG Die deutsche Ubersetzung dieser Handbuchseite wurde von Helge Kreutzmann erstellt. Diese Ubersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezuglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG ubernommen. Wenn Sie Fehler in der Ubersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Ubersetzer . systemd 255 JOURNALD.CONF(5)