SYSTEMD.JOURNAL-FIELDS(7) systemd.journal-fields SYSTEMD.JOURNAL-FIELDS(7) BEZEICHNUNG systemd.journal-fields - Besondere Journal-Felder BESCHREIBUNG Eintrage in dem Journal (wie von systemd-journald.service(8) geschrieben) ahneln in ihrer Syntax einem UNIX-Prozessumgebungsblock, aber mit Feldwerten, die binare Daten und uneindeutige Feldnamen enthalten durfen. Primar werden Feldwerte als UTF-8-Textzeichenketten formatiert. Binare Kodierung wird nur verwandt, wenn die Formatierung als UTF-8-Textzeichenkette wenig Sinn ergibt. Anwendungen durfen neue Felder frei definieren, ein paar Felder, die nachfolgend aufgefuhrt sind, haben eine besondere Bedeutung. Typischerweise durfen Felder nur einmal pro Protokolleintrag auftreten, allerdings gibt es besondere Ausnahmen: einige Felder durfen mehr als einmal pro Eintrag auftauchen; dies wird nachfolgend explizit erwahnt. Obwohl das Protokolluntersystem keine Beschrankungen vorgibt, fur welche Felder uneindeutige Werte akzeptiert werden, wird nachdrucklich empfohlen, sich fur die nachfolgend aufgefuhrten Felder nicht darauf zu verlassen (ausser wo dies wie erwahnt anders aufgefuhrt ist), um unnotige Inkompatibilitaten mit anderen Anwendungen zu vermeiden. BENUTZER-JOURNAL-FELDER Benutzerfelder sind Felder, die von Clients direkt weitergeleitet und im Journal gespeichert werden. MESSAGE= Die menschenlesbare Zeichenkette fur diesen Eintrag. Dies sollte der primare, dem Benutzer angezeigte Text sein. Er wird normalerweise nicht ubersetzt (konnte dies aber in einigen Fallen), und sollte nicht auf Metadaten ausgewertet werden. Um mehrzeilige Zeilen in einem einzigen Protokolleintrag zu kodieren, trennen Sie sie durch Zeilenumbruchzeichen (ASCII-Code 10), kodieren Sie aber als einziges Feld MESSAGE=. Fugen Sie nicht mehrere Werte dieses Feldtyps zu dem gleichen Eintrag hinzu (siehe oben), da nutzende Anwendungen dies im Allgemeinen nicht erwarten und in diesem Fall wahrscheinlich nicht alle Werte anzeigen werden. MESSAGE_ID= Eine 128-bit-Nachrichtkennzeichnungskennung zur Erkennung bestimmter Nachrichtentypen, falls dies gewunscht wird. Dies sollte eine 128-Bit-Kennung enthalten, die als hexadezimale Zeichenkette in Kleinschreibung ohne trennende Gedankenstriche und ahnliches formatiert ist. Es wird empfohlen, dass dies eine UUID-kompatible Kennung ist, dies wird aber nicht erzwungen und anders formatiert. Entwickler konnen eine neue Kennung fur diesen Zweck mit systemd-id128 new erstellen. PRIORITY= Ein als dezimale Zeichenkette formatierter Prioritatswert zwischen 0 (>>emerg<<) und 7 (>>debug<<). Dieses Feld ist zu dem Prioritatskonzept von Syslog kompatibel. CODE_FILE=, CODE_LINE=, CODE_FUNC= Der Code-Ort, der diese Nachricht erstellt, falls bekannt. Enthalt den Quelldateinamen, die Zeilennummer und den Funktionsnamen. ERRNO= Die systemnahe Unix-Fehlernummer, die diesen Eintrag hervorruft, falls vorhanden. Enthalt den als dezimale Zeichenkette formatierten numerischen Wert von errno(3). Hinzugefugt in Version 188. INVOCATION_ID=, USER_INVOCATION_ID= Eine zufallige, eindeutige 128-Bit-Kennung, die jeden Laufzeitzyklus der Unit identifiziert. Dies unterscheidet sich von _SYSTEMD_INVOCATION_ID darin, dass sie nur fur vom Systemd-Code kommende Nachrichten verwandt wird (z.B. Protokolle vom System-/Benutzerverwalter oder von mit Fork gestarteten Prozessen, die Systemd-bezogene Einrichtungen vornehmen). Hinzugefugt in Version 245. SYSLOG_FACILITY=, SYSLOG_IDENTIFIER=, SYSLOG_PID=, SYSLOG_TIMESTAMP= Syslog-Kompatibilitatsfelder, die die Einrichtung (formatiert als dezimale Zeichenkette), die Kennungszeichenkette (d.h. >>Markierung<<), die Client-PID und den Zeitstempel, wie er im ursprunglichen Datagram festgelegt wurde, enthalt. (Beachten Sie, dass die Markierung normalerweise von der Glibc-Variablen program_invocation_short_name abgeleitet wird, siehe program_invocation_short_name(3).) Beachten Sie, dass der Journal-Dienst die Werte keines strukturierten Journal-Feldes, dessen Namen kein Unterstrich vorangestellt ist, validiert. Hierzu gehoren samtliche Syslog-bezogenen Felder so wie diese. Daher wird erwartet, dass Anwendungen, die eine Einrichtung, PID oder eine Protokollierstufe bereitstellen, diese korrekt formatieren, d.h. als numerische Ganzzahlen, formatiert als Dezimalzeichenketten. SYSLOG_RAW= Der ursprungliche Inhalt der Syslog-Zeile, wie er im Syslog-Datagram empfangen wurde. Dieses Feld ist nur enthalten, wenn das Feld MESSAGE= im Vergleich zur ursprunglichen Nutzlast verandert oder der Zeitstempel nicht korrekt gefunden werden konnte und nicht im SYSLOG_TIMESTAMP= enthalten ist. Die Nachricht wird abgeschnitten, wenn die Nachricht einleitende oder abschliessende Leerraumzeichen enthalt (einleitende und abschliessende Leerraumzeichen werden entfernt) oder wenn sie ein eingebettetes Nullbyte (NUL) enthalt (das Nullbyte und alles danach ist nicht enthalten). Daher ist die ursprungliche Syslog-Zeile entweder in SYSLOG_RAW= gespeichert oder sie kann aus der abgespeicherten Prioritat und Einrichtung, Zeitstempel, Kenner und der Nachrichtennutzlast in MESSAGE= wiederhergestellt werden. Hinzugefugt in Version 240. DOCUMENTATION= Eine Dokumentations-URL mit weiteren Informationen uber das Thema der Protokollnachricht. Werkzeuge wie journalctl werden einen Hyperlink zu einer auf dieser Art festgelegten URL in ihrer Ausgabe aufnehmen. Sollte eine >>http://<<-, >>https://<<-, >>file:/<<-, >>man:<<- oder >>info:<<-URL sein. Hinzugefugt in Version 246. TID= Die numerische Thread-Kennung (TID), von dem der Journal-Eintrag stammt. Hinzugefugt in Version 247. UNIT=, USER_UNIT= Der Name der Unit. Wird von System- und Benutzerverwaltern beim Protokollieren uber bestimmte Units verwandt. Wenn --unit=name oder --user-unit=Name mit journalctl(1) verwandt werden, wird ein Abgleichmuster erstellt, das >>UNIT=Name.service<< oder >>USER_UNIT=Name.service<< enthalt. Hinzugefugt in Version 251. VERTRAUENSWURDIGE JOURNAL-FELDER Felder, die mit einem Unterstrich beginnen, sind vertrauenswurdige Felder, d.h. Felder, die implizit vom Journal hinzugefugt werden und durch Client-Code nicht geandert werden konnen. _PID=, _UID=, _GID= Die Prozess-, Benutzer- und Gruppenkennung des Prozesses, von dem der Journal-Eintrag stammt, formatiert als dezimale Zeichenkette. Beachten Sie, dass uber >>stdout<< und >>stderr<< von untergestarteten Prozessen erhaltene Eintrage die vom Elternprozess gultigen Berechtigungsnachweise (der die Verbindung zu systemd-journald etablierte) enthalten werden. _COMM=, _EXE=, _CMDLINE= Der Name, der Programmpfad und die Befehlzeile des Prozesses, von dem der Journal-Eintrag kommt. _CAP_EFFECTIVE= Die effektiven capabilities(7) des Prozesses, von dem der Journal-Eintrag kommt. Hinzugefugt in Version 206. _AUDIT_SESSION=, _AUDIT_LOGINUID= Die Sitzungs- und Anmelde-UID des Prozesses, von dem der Journal-Eintrag kommt, wie sie vom Kernel-Audit-Untersystem verwaltet wird. _SYSTEMD_CGROUP=, _SYSTEMD_SLICE=, _SYSTEMD_UNIT=, _SYSTEMD_USER_UNIT=, _SYSTEMD_USER_SLICE=, _SYSTEMD_SESSION=, _SYSTEMD_OWNER_UID= Der Steuergruppenpfad in der Systemd-Hierarchie, der Systemd-Scheiben-Unit-Name, der Systemd-Unit-Name, der Unit-Name in dem Systemd-Benutzerverwalter (falls zutreffend), die Systemd-Sitzungskennung (falls zutreffend) und die Eigentumer-UID der Systemd-Benutzer-Unit oder der Systemd-Sitzung (falls vorhanden) des Prozesses, von dem der Journal-Eintrag stammt. _SELINUX_CONTEXT= Der SELinux-Sicherheitskontext (Label) des Prozesses, von dem der Journal-Eintrag stammt. _SOURCE_REALTIME_TIMESTAMP= Der fruhste vertrauenswurdige Zeitstempel der Nachricht, falls einer bekannt ist, der sich vom Empfangszeitpunkt im Journal unterscheidet. Dies ist die Zeit in Mikrosekunden seit der Epoch-UTC, formatiert als dezimale Zeichenkette. _BOOT_ID= Die Kernel-Systemstartkennung fur den Systemstart, unter dem die Nachricht erstellt wurde, formatiert als 128-Bit hexadezimale Zeichenkette. _MACHINE_ID= Die Maschinenkennung des verursachenden Rechners, wie sie in machine-id(5) verfugbar ist. _SYSTEMD_INVOCATION_ID= Die Aufrufkennung fur den Laufzeitzyklus der Unit, unter der die Nachricht erstellt wurde, wie sie fur Prozesse der Unit in $INVOCATION_ID verfugbar ist (siehe systemd.exec(5)). Hinzugefugt in Version 233. _HOSTNAME= Der Name des verursachenden Rechners. _TRANSPORT= Wie der Eintrag vom Journal-Dienst empfangen wurde. Gultige Transporte sind: audit fur solche, die vom Kernel-Audit-Subsystem gelesen wurden Hinzugefugt in Version 227. driver fur intern erstellte Nachrichten Hinzugefugt in Version 205. syslog fur solche, die uber lokale Syslog-Sockets im Syslog-Protokoll empfangen wurden Hinzugefugt in Version 205. journal fur solche, die im nativen Journal-Protokoll empfangen wurden Hinzugefugt in Version 205. stdout fur solche, die aus der Standardausgabe oder der Standardfehlerausgabe eines Dienstes gelesen wurden Hinzugefugt in Version 205. kernel fur solche, die vom Kernel gelesen wurden Hinzugefugt in Version 205. _STREAM_ID= Gilt nur fur Datensatze >>_TRANSPORT=stdout<<: legt eine zufallige 128-Bit-Kennung, die der Datenstromverbindung zugeordnet wurde, als sie erstmalig erstellt wurde, fest. Diese Kennung ist zur Rekonstruktion individueller Protokolldatenstrome aus den Protokolldatensatzen nutzlich: alle Protokolldatensatze, die die gleiche Datenstromkennung tragen, stammen aus dem gleichen Datenstrom. Hinzugefugt in Version 235. _LINE_BREAK= Gilt nur fur Datensatze >>_TRANSPORT=stdout<<: zeigt an, dass die Protokollnachricht in der Standardausgabe/der Standardfehlerausgabe nicht mit einem normalen Zeilenumbruchzeichen (>>\n<<, d.h. ASCII 10) beendet wurde. Wenn gesetzt, ist dieses Feld insbesondere entweder nul (falls die Zeile durch ein Nullbyte (NUL) beendet wurde), line-max (falls die maximale Lange der Protokollzeile erreicht wurde, wie sie mit LineMax= in journald.conf(5) konfiguriert wurde), eof (falls dies der letzte Protokolleintrag in einem Datenstrom war und der Datenstrom ohne ein abschliessendes Zeilenumbruchzeichen endete) oder pid-change (falls der Prozess, der die Protokollausgabe erstellte, sich in der Mitte einer Zeile anderte). Beachten Sie, dass dieser Datensatz nicht erstellt wird, wenn ein normales Zeilenumbruchzeichen fur die Markierung des Endes der Protokollzeile verwandt wurde. Hinzugefugt in Version 235. _NAMESPACE= Falls diese Datei von einer systemd-journald-Instanz geschrieben wurde, die einen Namensraum verwaltete, der nicht die Vorgabe war, enthalt dieses Feld den Namensraumkennzeichner. Siehe systemd-journald.service(8) fur Details uber Journal-Namensraume. Hinzugefugt in Version 245. _RUNTIME_SCOPE= Ein Zeichenkettenfeld, das den Laufzeit-Geltungsbereich festlegt, in dem die Meldung protokolliert wurde. Falls >>initrd<<, wurde die Meldung verarbeitet, wahrend das System innerhalb der Initrd lief. Falls >>system<<, wurde die Meldung verarbeitet, nachdem das System die Ausfuhrung in das Wurzeldateisystem des Rechners transferiert hat. Hinzugefugt in Version 252. KERNEL-JOURNAL-FELDER Kernelfelder sind Felder, die fur vom Kernel stammende und im Journal gespeicherte Nachrichten verwandt werden. _KERNEL_DEVICE= Der Kernelgeratename. Falls der Eintrag einem Blockgerat zugeordnet ist, enthalt dies die Major- und Minornummern des Gerateknotens, getrennt durch >>:<< mit vorangestelltem >>b<<. Ahnlich fur zeichenorientierte Gerate, aber mit vorangestelltem >>c<<. Fur Netzwerkgerate ist dies der Schnittstellenindex mit vorangestelltem >>n<<. Fur alle anderen Gerate ist dies der Untersystemname mit vorangestelltem >>+<<, gefolgt von >>:<<, gefolgt vom Kernelgeratenamen. Hinzugefugt in Version 189. _KERNEL_SUBSYSTEM= Der Kernel-Untersystemname. Hinzugefugt in Version 189. _UDEV_SYSNAME= Der Kernelgeratename, wie er in dem Geratebaum unterhalb von /sys/ auftaucht. Hinzugefugt in Version 189. _UDEV_DEVNODE= Der Gerateknotenpfad dieses Gerates in /dev/. Hinzugefugt in Version 189. _UDEV_DEVLINK= Zusatzliche Symlinks, die auf den Gerateknoten in /dev/ zeigen. Dieses Feld ist haufig mehr als einmal pro Eintrag gesetzt. Hinzugefugt in Version 189. FELDER, DIE IM AUFTRAG EINES ANDEREN PROGRAMMS PROTOKOLLIERT WERDEN Felder in diesem Abschnitt werden von Programmen verwandt, um festzulegen, dass sie im Auftrag eines anderen Programmes oder einer anderen Unit protokollieren. Felder, die vom systemd-coredump Speicherauszug-Kernel-Hilfsprogramm verwandt werden: COREDUMP_UNIT=, COREDUMP_USER_UNIT= Wird zur Kommentierung von Nachrichten, die Speicherauszuge von System- und Sitzungs-Units enthalten, verwandt. Siehe coredumpctl(1). Hinzugefugt in Version 198. Privilegierte Programme (derzeit UID 0) konnen OBJECT_PID= an eine Nachricht anhangen. Dies weist systemd-journald an, zusatzliche Felder im Auftrag des Aufrufenden anzuhangen: OBJECT_PID=PID PID des Programms, zu dem diese Nachricht gehort. Hinzugefugt in Version 205. OBJECT_UID=, OBJECT_GID=, OBJECT_COMM=, OBJECT_EXE=, OBJECT_CMDLINE=, OBJECT_AUDIT_SESSION=, OBJECT_AUDIT_LOGINUID=, OBJECT_SYSTEMD_CGROUP=, OBJECT_SYSTEMD_SESSION=, OBJECT_SYSTEMD_OWNER_UID=, OBJECT_SYSTEMD_UNIT=, OBJECT_SYSTEMD_USER_UNIT= Dies sind zusatzliche Felder, die durch systemd-journald hinzugefugt werden. Ihre Bedeutung ist identisch zu _UID=, _GID=, _COMM=, _EXE=, _CMDLINE=, _AUDIT_SESSION=, _AUDIT_LOGINUID=, _SYSTEMD_CGROUP=, _SYSTEMD_SESSION=, _SYSTEMD_UNIT=, _SYSTEMD_USER_UNIT= und _SYSTEMD_OWNER_UID= wie oben beschrieben, ausser dass der durch PID identifizierte Prozess beschrieben wird, statt des Prozesses, der die Nachricht protokollierte. Hinzugefugt in Version 205. ADRESSFELDER Wahrend der Serialisierung in externe Formate wie dem Journal-Exportformat[1] oder dem Journal-JSON-Format[2] werden die Adressen der Journal-Eintrage in Felder serialisiert, die mit einem doppelten Unterstrich beginnen. Beachten Sie, dass diese keine gultigen Felder sind, wenn sie im Journal gespeichert sind, sondern zur Adressierung von Metadaten in Eintragen dienen. Sie konnen nicht als Teil von strukturierten Protokolleintragen uber Aufrufe wie sd_journal_send(3) geschrieben werden. Sie konnen auch nicht als Treffer fur sd_journal_add_match(3) verwandt werden. __CURSOR= Der Cursor fur den Eintrag. Ein Cursor ist eine undurchsichtige Textzeichenkette, die eindeutig die Position eines Eintrags im Journal beschreibt und uber Maschinen, Plattformen und Journal-Dateien hinweg portabel ist. __REALTIME_TIMESTAMP= Die echte Zeit (CLOCK_REALTIME) zum Zeitpunkt, zu dem der Eintrag im Journal empfangen wurde, in Mikrosekunden seit der Epoch-UTC, formatiert als dezimale Zeichenkette. Dies hat andere Eigenschaften als >>_SOURCE_REALTIME_TIMESTAMP=<< und ist normalerweise etwas spater aber wahrscheinlicher monoton. __MONOTONIC_TIMESTAMP= Die monotone Zeit (CLOCK_MONOTONIC) zum Zeitpunkt, zu dem der Eintrag im Journal empfangen wurde, in Mikrosekunden seit der Epoch-UTC, formatiert als dezimale Zeichenkette. Dies ist als Adresse fur den Eintrag nutzlich, sie sollte mit der Systemstartkennung in >>_BOOT_ID=<< kombiniert werden. __SEQNUM=, __SEQNUM_ID= Die Sequenznummer (und die zugehorige Sequenznummerkennung) aus der dieser Journal-Eintrag in der Journal-Datei stammt. Siehe sd_journal_get_seqnum(3) fur Details. Hinzugefugt in Version 254. SIEHE AUCH systemd(1), systemd-journald.service(8), journalctl(1), journald.conf(5), sd-journal(3), coredumpctl(1), systemd.directives(7) ANMERKUNGEN 1. Journal-Exportformat https://systemd.io/JOURNAL_EXPORT_FORMATS#journal-export-format 2. Journal-JSON-Format https://systemd.io/JOURNAL_EXPORT_FORMATS#journal-json-format UBERSETZUNG Die deutsche Ubersetzung dieser Handbuchseite wurde von 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.JOURNAL-FIELDS(7)