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(3)

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

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

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

       /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(3), 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>.

systemd 243                                                                          SYSTEMD-JOURNALD.SERVICE(8)