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 - Journal-Dienst

ÜBERSICHT

       systemd-journald.service

       systemd-journald.socket

       systemd-journald-dev-log.socket

       systemd-journald-audit.socket

       /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(4)

• 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^64-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.

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-Dienstemanager 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 NUL Bytes 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-Dienstemanager 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 Dienste-Manager 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.

Note that the log record metadata for records transferred via such standard output/error
streams reflect the metadata of the peer the stream was originally created for. If the
stream connection is passed on to other processes (such as further child processes forked
off the main service process), the log records will not reflect their metadata, but will
continue to describe the original process. This is different from the other logging
transports listed above, which are inherently record based and where the metadata is
always associated with the individual record.

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.

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. Der Befehl journalctl --flush verwendet
           dieses Signal, um die Übertragung der Journaldateien anzuweisen und anschließend auf
           den Abschluss des Vorgangs zu warten. Details hierzu finden Sie in journalctl(1).

       SIGUSR2
           Dadurch wird die sofortige Rotation der Journaldateien angefordert. Der Befehl
           journalctl --rotate verwendet dieses Signal, um das Rotieren der Journaldateien
           anzufordern.

       SIGRTMIN+1
           Dadurch wird angefordert, dass alle ungeschriebenen Protokolldaten auf Platte
           geschrieben werden. Der Befehl journalctl --sync verwendet dieses Signal, um die
           Journalsynchronisation auszulösen und wartet dann, dass diese Aktion abgeschlossen
           wird.

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.

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 angemeldete Benutzer seine eigenen Journaldateien in
       /var/log/journal/. Diese 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 Zugriffskontrolllisten (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).

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

       /dev/kmsg, /dev/log, /run/systemd/journal/dev-log, /run/systemd/journal/socket,
       /run/systemd/journal/stdout
           Sockets und andere Pfade, die im Dateisystem sichtbar sind und bei denen
           systemd-journald auf Nachrichten wartet. Zusätzlich zu diesen kann Journald mittels
           Netlink auf Auditereignisse warten.

SIEHE AUCH

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

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