BEZEICHNUNG
journald.conf, journald.conf.d, [email protected] - 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/*.confBESCHREIBUNG
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=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 [email protected] 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.
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.
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«.
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
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=
| Verfügbarer Plattenplatz | Signalfolgenmultiplikator |
| <= 1MB | 1 |
| <= 16MB | 2 |
| <= 256MB | 3 |
| <= 4GB | 4 |
| <= 64GB | 5 |
| <= 1TB | 6 |
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. 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.
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, 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=
Steuert die maximale Protokollierstufe
für 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 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 im Journal gespeichert 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, 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.
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. 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. Das bedeutet, dass systemd-journald sie
weiterhin sammeln wird, wenn zwar systemd-journald die Erzeugung
ausgestellt, ein andereres Werkzeug sie aber angestellt hat.
Standardmäßig aus.
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 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.
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 <[email protected]> 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 252 |