SYSTEMD-JOURNALD.SERVICE(8) systemd-journald.service 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 UBERSICHT 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: o Kernel-Protokollmeldungen (uber kmsg) o Einfache Systemprotokollmeldungen (uber den libc-Aufruf syslog(3)) o Strukturierte Systemprotokollmeldungen uber die native Journal-API, siehe sd_journal_print(3) und Natives Journal-Protokoll[1] o Standardausgabe und Standardfehlerausgabe der Dienste-Units. Siehe unten fur weitere Details. o Audit-Aufzeichnungen, stammend aus dem Kernel-Audit-Subsystem Der Daemon wird implizit sicher und unverfalschbar eine Reihe von Metadatenfeldern fur jede Protokollnachricht sammeln. Siehe systemd.journal-fields(7) fur weitere Informationen uber die gesammelten Metadaten. Die vom Journal gesammelten Protokolldaten sind vorwiegend textbasiert, konnen aber wo notwendig auch binare Daten enthalten. Einzelne Felder, die einen Protokolldatensatz im Journal darstellen, durfen bis zu 2-1 Byte gross sein. Der Journal-Dienst speichert Protokolldaten entweder dauerhaft unter /var/log/journal oder in einer verganglichen Art unter /run/log/journal/ (in letzterem Fall geht dies beim Systemneustart verloren). Standardmassig werden Protokolldaten dauerhaft gespeichert, falls /var/log/journal/ wahrend des Systemstarts existiert. Implizit wird auf vergangliche Speicherung andernfalls zuruckgefallen. Verwenden Sie Storage= in journald.conf(5), um den Speicherort von Protokolldaten unabhangig von der Existenz von /var/log/journal/ zu konfigurieren. Beachten Sie, dass Journald anfanglich fluchtigen Speicher verwenden wird, bis ein Aufruf von journalctl --flush (oder das Senden von SIGUSR1 an Journald) dazu fuhrt, dass er zum Protokollieren auf dauerhaften Speicher umschaltet (unter den oben erwahnten 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 erwunscht ist (und die Standard journald.conf verwandt wird) reicht es aus, das Verzeichnis zu erstellen, und sicherzustellen, dass die Zugriffsmodi und der Eigentumer 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 standardmassig mit dem Journal verbunden sind. Dieses Verhalten kann mit den Unit-Dateieinstellungen StandardOutput=/StandardError= geandert werden, siehe systemd.exec(5) fur Details. Das Journal konvertiert den auf diese Weise erhaltenen Protokoll-Byte-Strom in einzelne Protokolldatensatze. Der Strom wird bei Zeilenumbruchen (>>\n<<, ASCII 10) und Nullbytes (NUL) getrennt. Falls systemd-journald.service gestoppt wird, werden alle mit den Diensten zusammenhangende Dienste beendet. Um in diesen Fall hoflich 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 fuhren, dass solche Prozesssignale erstellt werden, siehe signal(7). Um diese Problem zu entscharfen, schaltet der Systemd-Diensteverwalter das Signal SIGPIPE fur alle aufgerufenen Prozesse standardmassig aus (dies kann fur jede Unit individuell mit der Option IgnoreSIGPIPE= geandert werden, siehe systemd.exec(5) fur Details). Nachdem die Standardausgabe/Standardfehler-Strome beendet wurden, konnen sie nicht zuruckgewonnen werden, bis die ihnen zugeordneten Dienste neu gestartet werden. Beachten Sie, dass im Normalbetrieb systemd-journald.service Kopien der Dateideskriptoren fur diese Streams in dem Diensteverwalter speichert. Falls systemd-journald.service mit systemctl restart oder aquivalenten Aktionen statt dem Parchen getrennter Befehle systemctl stop und systemctl start (oder aquivalenten Aktionen) neu gestartet wird, werden diese Stromverbindungen nicht beendet und uberleben den Neustart. Daher ist es sicher, systemd-journald.service neuzustarten, aber das Stoppen wird nicht empfohlen. Beachten Sie, dass die Metadaten des Protokolldatensatzes fur Datensatze, die uber solche Standard-Eingabe-/-Ausgabe-Datenstrome ubertragen werden, die Metadaten der Gegenstelle widerspiegeln, fur den sie ursprunglich erstellt wurden. Falls die Datenstromverbindung an einen anderen Prozess ubergeben wird (wie an einen weiteren, vom Hauptdiensteprozess mittels >>fork<< gestarteten Kindprozess), werden das die Kindprozesse nicht in ihren Metadaten widerspiegeln, sondern weiterhin den ursprunglichen Prozess beschreiben. Dies unterscheidet sich von anderen, oben beschriebenen Protokollierungstransporten, die inharent datensatzbasiert sind und bei denen die Metadaten stets dem individuellen Datensatz zugeordnet sind. Zusatzlich zu der impliziten Standardausgabe-/fehlerprotokollierung von Diensten ist die Stromprotokollierung auch uber das Befehlzeilenwerkzeug systemd-cat(1) verfugbar. Derzeit ist die Anzahl der parallelen Protokollstrome, die systemd-journald akzeptiert, auf 4096 begrenzt. Wenn diese Grenze erreicht wird, konnen weitere Protokollstrome etabliert werden, sie erhalten aber sofort EPIPE. JOURNAL-NAMENSRAUME Journal->>Namensraume<< sind sowohl ein Mechanismus zur logischen Isolation eines Protokolldatenstroms vom Rest des Systems fur Projekte, die aus einem oder mehreren Diensten bestehen, als auch ein Mechanismus zur Steigerung der Leistung. Es konnen mehrere Journal-Namensraume simultan existieren, bei der jeder seinen eigenen, unabhangigen Protokolldatenstrom durch seine eigene Instanz von systemd-journald verwaltet. Namensraume sind voneinander unabhangig, sowohl in dem Datenspeicher als auch in der IPC-Schnittstelle. Standardmassig existiert nur ein einzelner >>Vorgabe<<-Namensraum, der durch systemd-journald.service (und seine zugehorigen Socket-Units) verwaltet wird. Durch Starten einer Instanz der Dienstevorlage systemd-journald@.service werden zusatzliche Namensraume erstellt. Der Instanzenname ist der Namensraumkennzeichner, der eine kurze Zeichenkette ist, die zur Referenz des Journal-Namensraums verwandt wird. Einem bestimmten Journal-Namensraum konnen Dienste-Units mittels der Unit-Dateieinstellung LogNamespace= zugeordnet werden, siehe systemd.exec(5) fur 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 Namensraumen sind nicht sichtbar. Dienste, die einem bestimmten Protokollnamensraum zugeordnet sind, konnen mittels Syslog, dem nativen Protokollierprotokoll des Journals und mittels Stdout/Stderr protokollieren; die Protokollierung uber alle drei Transporte wird dem Namensraum zugeordnet. Standardmassig wird nur der Vorgabenamensraum Kernel- und Auditprotokollnachrichten sammeln. Die systemd-journald-Instanz des Vorgabenamensraums wird mittels /etc/systemd/journald.conf konfiguriert (siehe unten), wahrend andere Instanzen mittels /etc/systemd/journald@NAMENSRAUM.conf konfiguriert werden. Die Journal-Protokolldaten fur den Vorgabenamensraum werden unter /var/log/journal/MASCHINENKENNUNG abgelegt (siehe unten), wahrend sich die Daten fur andere Namensraume in /var/log/journal/MASCHINENKENNUNG.NAMENSRAUM befinden. SIGNALE SIGUSR1 Dadurch werden die fluchtigen Daten in /run/ nach /var/ geschrieben, um diese dauerhaft zu speichern (sofern dies aktiviert ist). Dies muss nach dem Einhangen von /var/ geschehen, da ansonsten niemals Daten von /run/ nach /var/ geschrieben werden wurden, unabhangig von der Konfiguration. Verwenden Sie den Befehl journalctl --flush, um die Ubertragung der Journaldateien anzuweisen und anschliessend auf den Abschluss des Vorgangs zu warten. Details hierzu finden Sie in journalctl(1). Hinzugefugt 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 anschliessend auf den Abschluss des Vorgangs zu warten. Hinzugefugt 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 auszulosen und dann zu warten, dass diese Aktion abgeschlossen wird. Hinzugefugt in Version 228. KERNEL-BEFEHLSZEILE Einige Konfigurationsparameter von journald.conf konnen auf der Befehlszeile ausser 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. Hinzugefugt in Version 186. Beachten Sie, dass diese Kernelbefehlszeilenoptionen nur vom Vorgabe-Namensraum berucksichtigt werden, siehe oben. ZUGRIFFSSTEUERUNG In der Voreinstellung gehoren die Jornaldateien der Systemgruppe >>systemd-journal<< und sind von dieser Gruppe lesbar, aber schreibgeschutzt. Das Hinzufugen eines Benutzers zu dieser Gruppe ermoglicht diesem somit, die Journaldateien zu lesen. In der Voreinstellung erhalt jeder Benutzer mit einer UID ausserhalb 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] fur weitere Details uber UID-Bereiche. Diese Journal-Dateien sind allerdings nicht Eigentum des jeweiligen Benutzers, damit vermieden wird, dass der Benutzer diese direkt andert. Stattdessen wird durch Dateisystem-ACLs sichergestellt, dass der Benutzer lediglich Lesezugriff erhalt. Weiteren Benutzern und Gruppen kann uber die Zugriffssteuerlisten (ACLs) des Dateisystems Zugriff auf die Journaldateien gewahrt werden. Distributionsentwickler und Administratoren konnen beispielsweise mit folgendem Befehl die Dateien fur 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 fur existierende Journaldateien als auch fur zukunftige im Verzeichnis /var/log/journal/ angelegte Journaldateien andert. DATEIEN /etc/systemd/journald.conf In dieser Datei wird das Verhalten von systemd-journald konfiguriert. Siehe journald.conf(5). Hinzugefugt 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 Eintrage 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 beschadigt sind, werden die Dateiendungen in >>.journal~<< umbenannt und systemd-journald schreibt in eine neue Datei. Wenn /var/log/journal nicht verfugbar 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 vollstandig geschriebenen Eintraege zu lesen. Systemd-journald wird automatisch die altesten archivierten Journal-Dateien entfernen, um die Plattenverwendung zu begrenzen. Siehe SystemMaxUse= und zugehorige Einstellungen in journald.conf(5). Hinzugefugt 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. Zusatzlich zu diesen kann systemd-journald mittels netlink(7) auf Auditereignisse warten, abhangig davon, ob >>systemd-journald-audit.socket<< aktiviert ist oder nicht. Hinzugefugt in Version 228. Falls Journal-Namensraume verwandt werden, werden diese Pfade wie oben beschrieben leicht verandert, 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 UBERSETZUNG Die deutsche Ubersetzung dieser Handbuchseite wurde von Mario Blattermann und Helge Kreutzmann erstellt. Diese Ubersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezuglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG ubernommen. Wenn Sie Fehler in der Ubersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Ubersetzer . systemd 255 SYSTEMD-JOURNALD.SERVICE(8)