Ubuntu Manpage: systemd-journald.service, systemd-journald.socket, systemd-journald-dev-log.socket,

BEZEICHNUNG

       systemd-journald.service, systemd-journald.socket, systemd-journald-dev-log.socket,
       systemd-journald-audit.socket, systemd-journald@.service, systemd-journald@.socket,
       systemd-journald-varlink@.socket, systemd-journald - Journal-Dienst

ÜBERSICHT

       systemd-journald.service

       systemd-journald.socket

       systemd-journald-dev-log.socket

       systemd-journald-audit.socket

       systemd-journald@.service

       systemd-journald@.socket

       systemd-journald-varlink@.socket

       /usr/lib/systemd/systemd-journald

BESCHREIBUNG

Systemd-journald ist ein Systemdienst, der Protokollmeldungen sammelt und speichert. Es
erstellt und verwaltet strukturierte, indizierte Journale, basierend auf den aus
verschiedenen Quellen empfangenen Protokollmeldungen:

• Kernel-Protokollmeldungen (über kmsg)

• Einfache Systemprotokollmeldungen (über den libc-Aufruf syslog(3))

• Strukturierte Systemprotokollmeldungen über die native Journal-API, siehe
sd_journal_print(3) und Natives Journal-Protokoll[1]

• Standardausgabe und Standardfehlerausgabe der Dienste-Units. Siehe unten für weitere
Details.

• Audit-Aufzeichnungen, stammend aus dem Kernel-Audit-Subsystem

Der Daemon wird implizit sicher und unverfälschbar eine Reihe von Metadatenfeldern für
jede Protokollnachricht sammeln. Siehe systemd.journal-fields(7) für weitere Informationen
über die gesammelten Metadaten.

Die vom Journal gesammelten Protokolldaten sind vorwiegend textbasiert, können aber wo
notwendig auch binäre Daten enthalten. Einzelne Felder, die einen Protokolldatensatz im
Journal darstellen, dürfen bis zu 2⁶⁴-1 Byte groß sein.

Der Journal-Dienst speichert Protokolldaten entweder dauerhaft unter /var/log/journal oder
in einer vergänglichen Art unter /run/log/journal/ (in letzterem Fall geht dies beim
Systemneustart verloren). Standardmäßig werden Protokolldaten dauerhaft gespeichert, falls
/var/log/journal/ während des Systemstarts existiert. Implizit wird auf vergängliche
Speicherung andernfalls zurückgefallen. Verwenden Sie Storage= in journald.conf(5), um den
Speicherort von Protokolldaten unabhängig von der Existenz von /var/log/journal/ zu
konfigurieren.

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

Auf Systemen, auf denen /var/log/journal/ noch nicht existiert aber auf denen dauerhafte
Protokollierung erwünscht ist (und die Standard journald.conf verwandt wird) reicht es
aus, das Verzeichnis zu erstellen, und sicherzustellen, dass die Zugriffsmodi und der
Eigentümer korrekt sind:

mkdir -p /var/log/journal
systemd-tmpfiles --create --prefix /var/log/journal

In journald.conf(5) finden Sie Informationen zur Konfiguration dieses Dienstes.

STROM-PROTOKOLLIERUNG

Der Systemd-Diensteverwalter ruft alle Diensteprozesse so auf, dass die Standardausgabe
und der Standardfehler standardmäßig mit dem Journal verbunden sind. Dieses Verhalten kann
mit den Unit-Dateieinstellungen StandardOutput=/StandardError= geändert werden, siehe
systemd.exec(5) für Details. Das Journal konvertiert den auf diese Weise erhaltenen
Protokoll-Byte-Strom in einzelne Protokolldatensätze. Der Strom wird bei Zeilenumbrüchen
(»\n«, ASCII 10) und Nullbytes (NUL) getrennt.

Falls systemd-journald.service gestoppt wird, werden alle mit den Diensten
zusammenhängende Dienste beendet. Um in diesen Fall höflich zu reagieren wird empfohlen,
dass Programme, die in die Standardausgabe/den Standardfehler protokollieren, solche
Fehler ignorieren. Falls der UNIX-Signal-Handler SIGPIPE nicht blockiert oder abgeschaltet
ist, werden solche Schreibversuche auch dazu führen, dass solche Prozesssignale erstellt
werden, siehe signal(7). Um diese Problem zu entschärfen, schaltet der
Systemd-Diensteverwalter das Signal SIGPIPE für alle aufgerufenen Prozesse standardmäßig
aus (dies kann für jede Unit individuell mit der Option IgnoreSIGPIPE= geändert werden,
siehe systemd.exec(5) für Details). Nachdem die Standardausgabe/Standardfehler-Ströme
beendet wurden, können sie nicht zurückgewonnen werden, bis die ihnen zugeordneten Dienste
neu gestartet werden. Beachten Sie, dass im Normalbetrieb systemd-journald.service Kopien
der Dateideskriptoren für diese Streams in dem Diensteverwalter speichert. Falls
systemd-journald.service mit systemctl restart oder äquivalenten Aktionen statt dem
Pärchen getrennter Befehle systemctl stop und systemctl start (oder äquivalenten Aktionen)
neu gestartet wird, werden diese Stromverbindungen nicht beendet und überleben den
Neustart. Daher ist es sicher, systemd-journald.service neuzustarten, aber das Stoppen
wird nicht empfohlen.

Beachten Sie, dass die Metadaten des Protokolldatensatzes für Datensätze, die über solche
Standard-Eingabe-/-Ausgabe-Datenströme übertragen werden, die Metadaten der Gegenstelle
widerspiegeln, für den sie ursprünglich erstellt wurden. Falls die Datenstromverbindung an
einen anderen Prozess übergeben wird (wie an einen weiteren, vom Hauptdiensteprozess
mittels »fork« gestarteten Kindprozess), werden das die Kindprozesse nicht in ihren
Metadaten widerspiegeln, sondern weiterhin den ursprünglichen Prozess beschreiben. Dies
unterscheidet sich von anderen, oben beschriebenen Protokollierungstransporten, die
inhärent datensatzbasiert sind und bei denen die Metadaten stets dem individuellen
Datensatz zugeordnet sind.

Zusätzlich zu der impliziten Standardausgabe-/fehlerprotokollierung von Diensten ist die
Stromprotokollierung auch über das Befehlzeilenwerkzeug systemd-cat(1) verfügbar.

Derzeit ist die Anzahl der parallelen Protokollströme, die systemd-journald akzeptiert,
auf 4096 begrenzt. Wenn diese Grenze erreicht wird, können weitere Protokollströme
etabliert werden, sie erhalten aber sofort EPIPE.

JOURNAL-NAMENSRÄUME

Journal-»Namensräume« sind sowohl ein Mechanismus zur logischen Isolation eines
Protokolldatenstroms vom Rest des Systems für Projekte, die aus einem oder mehreren
Diensten bestehen, als auch ein Mechanismus zur Steigerung der Leistung. Es können mehrere
Journal-Namensräume simultan existieren, bei der jeder seinen eigenen, unabhängigen
Protokolldatenstrom durch seine eigene Instanz von systemd-journald verwaltet. Namensräume
sind voneinander unabhängig, sowohl in dem Datenspeicher als auch in der
IPC-Schnittstelle. Standardmäßig existiert nur ein einzelner »Vorgabe«-Namensraum, der
durch systemd-journald.service (und seine zugehörigen Socket-Units) verwaltet wird. Durch
Starten einer Instanz der Dienstevorlage systemd-journald@.service werden zusätzliche
Namensräume erstellt. Der Instanzenname ist der Namensraumkennzeichner, der eine kurze
Zeichenkette ist, die zur Referenz des Journal-Namensraums verwandt wird. Einem bestimmten
Journal-Namensraum können Dienste-Units mittels der Unit-Dateieinstellung LogNamespace=
zugeordnet werden, siehe systemd.exec(5) für Details. Der Schalter --namespace= von
journalctl(1) kann zur Betrachtung des Protokolldatenstroms eines bestimmten Namensraums
verwandt werden. Falls der Schalter nicht verwandt wird, wird der Protokolldatenstrom des
Vorgabe-Namensraums verwandt, d.h. die Protokolldaten aus anderen Namensräumen sind nicht
sichtbar.

Dienste, die einem bestimmten Protokollnamensraum zugeordnet sind, können mittels Syslog,
dem nativen Protokollierprotokoll des Journals und mittels Stdout/Stderr protokollieren;
die Protokollierung über alle drei Transporte wird dem Namensraum zugeordnet.

Standardmäßig wird nur der Vorgabenamensraum Kernel- und Auditprotokollnachrichten
sammeln.

Die systemd-journald-Instanz des Vorgabenamensraums wird mittels
/etc/systemd/journald.conf konfiguriert (siehe unten), während andere Instanzen mittels
/etc/systemd/journald@NAMENSRAUM.conf konfiguriert werden. Die Journal-Protokolldaten für
den Vorgabenamensraum werden unter /var/log/journal/MASCHINENKENNUNG abgelegt (siehe
unten), während sich die Daten für andere Namensräume in
/var/log/journal/MASCHINENKENNUNG.NAMENSRAUM befinden.

SIGNALE

       SIGUSR1
           Dadurch werden die flüchtigen Daten in /run/ nach /var/ geschrieben, um diese
           dauerhaft zu speichern (sofern dies aktiviert ist). Dies muss nach dem Einhängen von
           /var/ geschehen, da ansonsten niemals Daten von /run/ nach /var/ geschrieben werden
           würden, unabhängig von der Konfiguration. Verwenden Sie den Befehl journalctl --flush,
           um die Übertragung der Journaldateien anzuweisen und anschließend auf den Abschluss
           des Vorgangs zu warten. Details hierzu finden Sie in journalctl(1).

           Hinzugefügt in Version 186.

       SIGUSR2
           Dadurch wird die sofortige Rotation der Journaldateien angefordert. Verwenden Sie den
           Befehl journalctl --rotate, um das Rotieren der Journaldateien anzufordern und
           anschließend auf den Abschluss des Vorgangs zu warten.

           Hinzugefügt in Version 186.

       SIGRTMIN+1
           Dadurch wird angefordert, dass alle ungeschriebenen Protokolldaten auf Platte
           geschrieben werden. Verwenden Sie den Befehl journalctl --sync, um die
           Journalsynchronisation auszulösen und dann zu warten, dass diese Aktion abgeschlossen
           wird.

           Hinzugefügt in Version 228.

KERNEL-BEFEHLSZEILE

       Einige Konfigurationsparameter von journald.conf können auf der Befehlszeile außer Kraft
       gesetzt werden:

       systemd.journald.forward_to_syslog=, systemd.journald.forward_to_kmsg=,
       systemd.journald.forward_to_console=, systemd.journald.forward_to_wall=
           Dies aktiviert/deaktiviert die Weiterleitung der gesammelten Protokollmeldungen in das
           Systemprotokoll, den Protokollpuffer des Kernels oder die »Wall« (Bildschirmmeldung in
           der Konsole).

           In journald.conf(5) finden Sie Informationen zu diesen Einstellungen.

           Hinzugefügt in Version 186.

       Beachten Sie, dass diese Kernelbefehlszeilenoptionen nur vom Vorgabe-Namensraum
       berücksichtigt werden, siehe oben.

ZUGRIFFSSTEUERUNG

In der Voreinstellung gehören die Jornaldateien der Systemgruppe »systemd-journal« und
sind von dieser Gruppe lesbar, aber schreibgeschützt. Das Hinzufügen eines Benutzers zu
dieser Gruppe ermöglicht diesem somit, die Journaldateien zu lesen.

In der Voreinstellung erhält jeder Benutzer mit einer UID außerhalb des Bereichs der
Systembenutzer, dynamischer Dienste-Benutzer und dem Benutzer »nobody« seine eigenen
Journaldateien in /var/log/journal/. Siehe Benutzer, Gruppen, UIDs und GIDs auf
Systemd-Systemen[2] für weitere Details über UID-Bereiche. Diese Journal-Dateien sind
allerdings nicht Eigentum des jeweiligen Benutzers, damit vermieden wird, dass der
Benutzer diese direkt ändert. Stattdessen wird durch Dateisystem-ACLs sichergestellt, dass
der Benutzer lediglich Lesezugriff erhält.

Weiteren Benutzern und Gruppen kann über die Zugriffssteuerlisten (ACLs) des Dateisystems
Zugriff auf die Journaldateien gewährt werden. Distributionsentwickler und Administratoren
können beispielsweise mit folgendem Befehl die Dateien für alle Mitglieder der
Systemgruppen »wheel« und »admin« lesbar machen:

# setfacl -Rnm g:wheel:rx,d:g:wheel:rx,g:adm:rx,d:g:adm:rx /var/log/journal/

Beachten Sie, dass dieser Befehl die ACLs sowohl für existierende Journaldateien als auch
für zukünftige im Verzeichnis /var/log/journal/ angelegte Journaldateien ändert.

DATEIEN

/etc/systemd/journald.conf
In dieser Datei wird das Verhalten von systemd-journald konfiguriert. Siehe
journald.conf(5).

Hinzugefügt in Version 206.

/run/log/journal/Maschinenkennung/*.journal, /run/log/journal/Maschinenkennung/*.journal~,
/var/log/journal/Maschinenkennung/*.journal, /var/log/journal/Maschinenkennung/*.journal~
systemd-journald schreibt Einträge in Dateien mit der Endung ».journal« in den
Verzeichnissen /run/log/journal/Maschinenkennung/ oder
/var/log/journal/Maschinenkennung/. Beim unsauberen Beenden des Hintergrunddienstes
oder wenn die gefundenen Dateien beschädigt sind, werden die Dateiendungen in
».journal~« umbenannt und systemd-journald schreibt in eine neue Datei. Wenn
/var/log/journal nicht verfügbar ist oder wenn Storage=volatile in der
Konfigurationsdatei journald.conf(5) gesetzt ist, wird /run/ verwendet.

Wenn Systemd-journald das Schreiben in eine Journal-Datei einstellt, wird diese in
»Ursprungsname@Endung.journal« (oder »Ursprungsname@Endung.journal~«) umbenannt.
Solche Dateien sind »archiviert« und es wird nicht mehr in sie geschrieben.

Im Allgemeinen ist es sicher, jede Journal-Datei zu lesen oder zu kopieren (aktiv oder
archiviert). journalctl(1) und die Funktionen aus der Bibliothek sd-journal(3) sollten
in der Lage sein, alle vollständig geschriebenen Einträege zu lesen.

Systemd-journald wird automatisch die ältesten archivierten Journal-Dateien entfernen,
um die Plattenverwendung zu begrenzen. Siehe SystemMaxUse= und zugehörige
Einstellungen in journald.conf(5).

Hinzugefügt in Version 206.

/dev/kmsg, /dev/log, /run/systemd/journal/dev-log, /run/systemd/journal/socket,
/run/systemd/journal/stdout
Sockets und andere Dateiknotenpfade, bei denen systemd-journald im Dateisystem auf
Meldungen warten wird und die dort sichtbar sind. Zusätzlich zu diesen kann
systemd-journald mittels netlink(7) auf Auditereignisse warten, abhängig davon, ob
»systemd-journald-audit.socket« aktiviert ist oder nicht.

Hinzugefügt in Version 228.

Falls Journal-Namensräume verwandt werden, werden diese Pfade wie oben beschrieben leicht
verändert, um einen Namensraumkennzeichner aufzunehmen.

SIEHE AUCH

       systemd(1), journalctl(1), journald.conf(5), systemd.journal-fields(7), sd-journal(3),
       systemd-coredump(8), setfacl(1), sd_journal_print(3), pydoc systemd.journal

ANMERKUNGEN

        1. Natives Journal-Protokoll
           https://systemd.io/JOURNAL_NATIVE_PROTOCOL

        2. Benutzer, Gruppen, UIDs und GIDs auf Systemd-Systemen
           https://systemd.io/UIDS-GIDS

ÜBERSETZUNG

       Die deutsche Übersetzung dieser Handbuchseite wurde von Mario Blättermann
       <mario.blaettermann@gmail.com> und Helge Kreutzmann <debian@helgefjell.de> erstellt.

       Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License
       Version 3 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ 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 ⟨debian-l10n-german@lists.debian.org⟩.