BEZEICHNUNG¶

ÜBERSICHT¶

systemd-journald.socket

systemd-journald-dev-log.socket

systemd-journald-audit.socket

systemd-journald@.service

systemd-journald@.socket

systemd-journald-varlink@.socket

/lib/systemd/systemd-journald

BESCHREIBUNG¶

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¶

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¶

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¶

SIGUSR2

SIGRTMIN+1

KERNEL-BEFEHLSZEILE¶

systemd.journald.forward_to_syslog=, systemd.journald.forward_to_kmsg=, systemd.journald.forward_to_console=, systemd.journald.forward_to_wall=

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

ZUGRIFFSSTEUERUNG¶

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[1] für weitere Dteails ü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¶

/run/log/journal/Maschinenkennung/*.journal, /run/log/journal/Maschinenkennung/*.journal~, /var/log/journal/Maschinenkennung/*.journal, /var/log/journal/Maschinenkennung/*.journal~

/dev/kmsg, /dev/log, /run/systemd/journal/dev-log, /run/systemd/journal/socket, /run/systemd/journal/stdout

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

SIEHE AUCH¶

ANMERKUNGEN¶

1.

Benutzer, Gruppen, UIDs und GIDs auf Systemd-Systemen

ÜBERSETZUNG¶

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