BEZEICHNUNG¶
systemd.journal-fields - Besondere Journal-Felder
BESCHREIBUNG¶
Einträge in dem Journal (wie von
systemd-journald.service(8) geschrieben) ähneln in ihrer
Syntax einem UNIX-Prozessumgebungsblock, aber mit Feldwerten, die
binäre Daten und uneindeutige Feldnamen enthalten dürfen.
Primär werden Feldwerte als UTF-8-Textzeichenketten formatiert.
Binäre Kodierung wird nur verwandt, wenn die Formatierung als
UTF-8-Textzeichenkette wenig Sinn ergibt. Anwendungen dürfen neue
Felder frei definieren, ein paar Felder, die nachfolgend aufgeführt
sind, haben eine besondere Bedeutung. Typischerweise dürfen Felder
nur einmal pro Protokolleintrag auftreten, allerdings gibt es besondere
Ausnahmen: einige Felder dürfen mehr als einmal pro Eintrag
auftauchen; dies wird nachfolgend explizit erwähnt. Obwohl das
Protokolluntersystem keine Beschränkungen vorgibt, für welche
Felder uneindeutige Werte akzeptiert werden, wird nachdrücklich
empfohlen, sich für die nachfolgend aufgeführten Felder nicht
darauf zu verlassen (außer wo dies wie erwähnt anders
aufgeführt ist), um unnötige Inkompatibilitäten 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 für diesen
Eintrag. Dies sollte der primäre, dem Benutzer angezeigte Text sein. Er
wird normalerweise nicht übersetzt (könnte dies aber in einigen
Fällen), 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=. Fügen 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 gewünscht wird. Dies sollte
eine 128-Bit-Kennung enthalten, die als hexadezimale Zeichenkette in
Kleinschreibung ohne trennende Gedankenstriche und ähnliches formatiert
ist. Es wird empfohlen, dass dies eine UUID-kompatible Kennung ist, dies wird
aber nicht erzwungen und anders formatiert. Entwickler können eine neue
Kennung für diesen Zweck mit systemd-id128 new erstellen.
PRIORITY=
Ein als dezimale Zeichenkette formatierter
Prioritätswert zwischen 0 (»emerg«) und 7
(»debug«). Dieses Feld ist zu dem Prioritätskonzept von
Syslog kompatibel.
CODE_FILE=, CODE_LINE=, CODE_FUNC=
Der Code-Ort, der diese Nachricht erstellt, falls
bekannt. Enthält den Quelldateinamen, die Zeilennummer und den
Funktionsnamen.
ERRNO=
Die systemnahe Unix-Fehlernummer, die diesen Eintrag
hervorruft, falls vorhanden. Enthält den als dezimale Zeichenkette
formatierten numerischen Wert von
errno(3).
Hinzugefügt in Version 188.
INVOCATION_ID=, USER_INVOCATION_ID=
Eine zufällige, eindeutige 128-Bit-Kennung, die
jeden Laufzeitzyklus der Unit identifiziert. Dies unterscheidet sich von
_SYSTEMD_INVOCATION_ID darin, dass sie nur für vom Systemd-Code
kommende Nachrichten verwandt wird (z.B. Protokolle vom
System-/Benutzerverwalter oder von mit Fork gestarteten Prozessen, die
Systemd-bezogene Einrichtungen vornehmen).
Hinzugefügt in Version 245.
SYSLOG_FACILITY=, SYSLOG_IDENTIFIER=,
SYSLOG_PID=, SYSLOG_TIMESTAMP=
Syslog-Kompatibilitätsfelder, die die Einrichtung
(formatiert als dezimale Zeichenkette), die Kennungszeichenkette (d.h.
»Markierung«), die Client-PID und den Zeitstempel, wie er im
ursprünglichen Datagram festgelegt wurde, enthält. (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 gehören sämtliche 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 ursprüngliche Inhalt der Syslog-Zeile, wie er
im Syslog-Datagram empfangen wurde. Dieses Feld ist nur enthalten, wenn das
Feld
MESSAGE= im Vergleich zur ursprünglichen Nutzlast
verändert oder der Zeitstempel nicht korrekt gefunden werden konnte und
nicht im
SYSLOG_TIMESTAMP= enthalten ist. Die Nachricht wird
abgeschnitten, wenn die Nachricht einleitende oder abschließende
Leerraumzeichen enthält (einleitende und abschließende
Leerraumzeichen werden entfernt) oder wenn sie ein eingebettetes Nullbyte
(
NUL) enthält (das Nullbyte und alles danach ist nicht
enthalten). Daher ist die ursprüngliche Syslog-Zeile entweder in
SYSLOG_RAW= gespeichert oder sie kann aus der abgespeicherten
Priorität und Einrichtung, Zeitstempel, Kenner und der
Nachrichtennutzlast in
MESSAGE= wiederhergestellt werden.
Hinzugefügt in Version 240.
DOCUMENTATION=
Eine Dokumentations-URL mit weiteren Informationen
über 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.
Hinzugefügt in Version 246.
TID=
Die numerische Thread-Kennung (TID), von dem der
Journal-Eintrag stammt.
Hinzugefügt in Version 247.
UNIT=, USER_UNIT=
Der Name der Unit. Wird von System- und
Benutzerverwaltern beim Protokollieren über 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« enthält.
Hinzugefügt in Version 251.
VERTRAUENSWÜRDIGE JOURNAL-FELDER¶
Felder, die mit einem Unterstrich beginnen, sind
vertrauenswürdige Felder, d.h. Felder, die implizit vom Journal
hinzugefügt werden und durch Client-Code nicht geändert werden
können.
_PID=, _UID=, _GID=
Die Prozess-, Benutzer- und Gruppenkennung des Prozesses,
von dem der Journal-Eintrag stammt, formatiert als dezimale Zeichenkette.
Beachten Sie, dass über »stdout« und
»stderr« von untergestarteten Prozessen erhaltene
Einträge die vom Elternprozess gültigen 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.
Hinzugefügt 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 Eigentümer-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 frühste vertrauenswürdige 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 für 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) verfügbar ist.
_SYSTEMD_INVOCATION_ID=
Die Aufrufkennung für den Laufzeitzyklus der Unit,
unter der die Nachricht erstellt wurde, wie sie für Prozesse der Unit
in
$INVOCATION_ID verfügbar ist (siehe
systemd.exec(5)).
Hinzugefügt in Version 233.
_HOSTNAME=
Der Name des verursachenden Rechners.
_TRANSPORT=
Wie der Eintrag vom Journal-Dienst empfangen wurde.
Gültige Transporte sind:
audit
für solche, die vom Kernel-Audit-Subsystem gelesen
wurden
Hinzugefügt in Version 227.
driver
für intern erstellte Nachrichten
Hinzugefügt in Version 205.
syslog
für solche, die über lokale Syslog-Sockets
im Syslog-Protokoll empfangen wurden
Hinzugefügt in Version 205.
journal
für solche, die im nativen Journal-Protokoll
empfangen wurden
Hinzugefügt in Version 205.
stdout
für solche, die aus der Standardausgabe oder der
Standardfehlerausgabe eines Dienstes gelesen wurden
Hinzugefügt in Version 205.
kernel
für solche, die vom Kernel gelesen wurden
Hinzugefügt in Version 205.
_STREAM_ID=
Gilt nur für Datensätze
»_TRANSPORT=stdout«: legt eine zufällige 128-Bit-Kennung,
die der Datenstromverbindung zugeordnet wurde, als sie erstmalig erstellt
wurde, fest. Diese Kennung ist zur Rekonstruktion individueller
Protokolldatenströme aus den Protokolldatensätzen
nützlich: alle Protokolldatensätze, die die gleiche
Datenstromkennung tragen, stammen aus dem gleichen Datenstrom.
Hinzugefügt in Version 235.
_LINE_BREAK=
Gilt nur für Datensätze
»_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 Länge 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 abschließendes Zeilenumbruchzeichen endete) oder
pid-change (falls der Prozess, der die Protokollausgabe erstellte, sich
in der Mitte einer Zeile änderte). Beachten Sie, dass dieser Datensatz
nicht erstellt wird, wenn ein normales Zeilenumbruchzeichen für die
Markierung des Endes der Protokollzeile verwandt wurde.
Hinzugefügt in Version 235.
_NAMESPACE=
Falls diese Datei von einer
systemd-journald-Instanz geschrieben wurde, die einen Namensraum
verwaltete, der nicht die Vorgabe war, enthält dieses Feld den
Namensraumkennzeichner. Siehe
systemd-journald.service(8) für
Details über Journal-Namensräume.
Hinzugefügt in Version 245.
_RUNTIME_SCOPE=
Ein Zeichenkettenfeld, das den Laufzeit-Geltungsbereich
festlegt, in dem die Meldung protokolliert wurde. Falls
»initrd«, wurde die Meldung verarbeitet, während das
System innerhalb der Initrd lief. Falls »system«, wurde die
Meldung verarbeitet, nachdem das System die Ausführung in das
Wurzeldateisystem des Rechners transferiert hat.
Hinzugefügt in Version 252.
KERNEL-JOURNAL-FELDER¶
Kernelfelder sind Felder, die für vom Kernel stammende und
im Journal gespeicherte Nachrichten verwandt werden.
_KERNEL_DEVICE=
Der Kernelgerätename. Falls der Eintrag einem
Blockgerät zugeordnet ist, enthält dies die Major- und
Minornummern des Geräteknotens, getrennt durch »:« mit
vorangestelltem »b«. Ähnlich für
zeichenorientierte Geräte, aber mit vorangestelltem »c«.
Für Netzwerkgeräte ist dies der Schnittstellenindex mit
vorangestelltem »n«. Für alle anderen Geräte ist
dies der Untersystemname mit vorangestelltem »+«, gefolgt von
»:«, gefolgt vom Kernelgerätenamen.
Hinzugefügt in Version 189.
_KERNEL_SUBSYSTEM=
Der Kernel-Untersystemname.
Hinzugefügt in Version 189.
_UDEV_SYSNAME=
Der Kernelgerätename, wie er in dem
Gerätebaum unterhalb von /sys/ auftaucht.
Hinzugefügt in Version 189.
_UDEV_DEVNODE=
Der Geräteknotenpfad dieses Gerätes in
/dev/.
Hinzugefügt in Version 189.
_UDEV_DEVLINK=
Zusätzliche Symlinks, die auf den
Geräteknoten in /dev/ zeigen. Dieses Feld ist häufig mehr als
einmal pro Eintrag gesetzt.
Hinzugefügt 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
Speicherauszüge von System- und Sitzungs-Units enthalten, verwandt.
Siehe
coredumpctl(1).
Hinzugefügt in Version 198.
Privilegierte Programme (derzeit UID 0) können
OBJECT_PID= an eine Nachricht anhängen. Dies weist
systemd-journald an, zusätzliche Felder im Auftrag des
Aufrufenden anzuhängen:
OBJECT_PID=PID
PID des Programms, zu dem diese Nachricht gehört.
Hinzugefügt 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 zusätzliche Felder, die durch
systemd-journald hinzugefügt 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, außer dass der durch
PID identifizierte Prozess
beschrieben wird, statt des Prozesses, der die Nachricht protokollierte.
Hinzugefügt in Version 205.
OBJECT_SYSTEMD_INVOCATION_ID=
Ein durch
systemd-journald automatisch
hinzugefügtes zusätzliches Feld. Die Bedeutung ist
größtenteils die gleiche wie bei
_SYSTEMD_INVOCATION_ID=,
mit den oben beschriebenen Unterschieden.
Hinzugefügt in Version 235.
ADRESSFELDER¶
Während der Serialisierung in externe Formate wie dem
Journal-Exportformat[1] oder dem Journal-JSON-Format[2] werden
die Adressen der Journal-Einträge in Felder serialisiert, die mit
einem doppelten Unterstrich beginnen. Beachten Sie, dass diese keine
gültigen Felder sind, wenn sie im Journal gespeichert sind, sondern
zur Adressierung von Metadaten in Einträgen dienen. Sie können
nicht als Teil von strukturierten Protokolleinträgen über
Aufrufe wie sd_journal_send(3) geschrieben werden. Sie können
auch nicht als Treffer für sd_journal_add_match(3) verwandt
werden.
__CURSOR=
Der Cursor für den Eintrag. Ein Cursor ist eine
undurchsichtige Textzeichenkette, die eindeutig die Position eines Eintrags im
Journal beschreibt und über 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
später 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
für den Eintrag nützlich, sie sollte mit der Systemstartkennung
in »_BOOT_ID=« kombiniert werden.
__SEQNUM=, __SEQNUM_ID=
Die Sequenznummer (und die zugehörige
Sequenznummerkennung) aus der dieser Journal-Eintrag in der Journal-Datei
stammt. Siehe
sd_journal_get_seqnum(3) für Details.
Hinzugefügt in Version 254.
ANMERKUNGEN¶
- 1.
- Journal-Exportformat
- 2.
- Journal-JSON-Format
ÜBERSETZUNG¶
Die deutsche Übersetzung dieser Handbuchseite wurde von
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 die
Mailingliste
der Übersetzer.
