BEZEICHNUNG
systemd.journal-fields - Besondere Journal-FelderBESCHREIBUNG
Einträge in dem Journal (wie von systemd-journald.service(8) geschrieben) ähneln in ihrer Syntax einem UNIX-Prozessumgebungsblock, aber mit Feldern, die binäre Daten enthalten dürfen. Primär werden Felder 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 haben aber eine besondere Bedeutung. Alle Felder mit besonderer Bedeutung sind optional. In manchen Fällen darf ein Feld mehr als einmal pro Eintrag auftauchen.BENUTZER-JOURNAL-FELDER
Benutzerfelder sind Felder, die von Clients direkt weitergeleitet und im Journal gespeichert werden. MESSAGE=Die menschenlesbare Nachricht für diese
Eintrag. Dies sollte der primäre, dem Benutzer gezeigte Text sein.
Normalerweise ist er nicht übersetzt (kann das in Einzelfällen
aber sein) und sollte nicht nach Metadaten ausgewertet 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).
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).
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.
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.
TID=
Die numerische Thread-Kennung (TID), von dem
der Journal-Eintrag stammt.
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.
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.
_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)).
_HOSTNAME=
Der Name des verursachenden Rechners.
_TRANSPORT=
Wie der Eintrag vom Journal-Dienst empfangen
wurde. Gültige Transporte sind:
audit
_STREAM_ID=
für solche, die vom
Kernel-Audit-Subsystem gelesen wurden
driver
für intern erstellte Nachrichten
syslog
für solche, die über lokale
Syslog-Sockets im Syslog-Protokoll empfangen wurden
journal
für solche, die im nativen
Journal-Protokoll empfangen wurden
stdout
für solche, die aus der Standardausgabe
oder der Standardfehlerausgabe eines Dienstes gelesen wurden
kernel
für solche, die vom Kernel gelesen
wurden
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.
_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.
_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.
_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.
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.
_KERNEL_SUBSYSTEM=
Der Kernel-Untersystemname.
_UDEV_SYSNAME=
Der Kernelgerätename, wie er in dem
Gerätebaum unterhalb von /sys/ auftaucht.
_UDEV_DEVNODE=
Der Geräteknotenpfad dieses
Gerätes in /dev/.
_UDEV_DEVLINK=
Zusätzliche Symlinks, die auf den
Geräteknoten in /dev/ zeigen. Dieses Feld ist häufig mehr als
einmal pro Eintrag gesetzt.
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).
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.
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.
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.
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
- 2.
- Journal-JSON-Format
ÜBERSETZUNG
Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann <[email protected]> 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 Übersetzersystemd 252 |