Provided by: manpages-de_2.16-1_all bug

BEZEICHNUNG

       systemd.journal-fields - Besondere Journal-Felder

BESCHREIBUNG

       Einträge in dem Journal ähneln in ihrer Syntax einem Umgebungsblock, aber mit Feldern, die
       binäre Daten enthalten können. Primär werden Felder als UTF-8-Textzeichenketten
       formatiert. Binäre Formatierung 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).

       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
           NUL-Byte enthält (das NUL-Byte 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.

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

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

       _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 NUL-Byte beendet wurde),
           line-max (falls die maximale Länge der Protokollzeile erreicht wurde, wie sie mit
           LineMax= in journald.conf(5) konfiguriert wurde) oder eof (falls dies der letzte
           Protokolleintrag in einem Datenstrom war und der Datenstrom ohne ein abschließendes
           Zeilenumbruchzeichen endete). Beachten Sie, dass dieser Datensatz nicht erstellt wird,
           wenn ein normales Zeilenumbruchzeichen für die Markierung des Endes der Protokollzeile
           verwandt wurde.

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, die Major und
           Minor 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), journalctl(1), journald.conf(5), sd-journal(3), coredumpctl(1),
       systemd.directives(7)

ANMERKUNGEN

        1. Journal-Exportformat
           https://www.freedesktop.org/wiki/Software/systemd/export

        2. Journal-JSON-Format
           https://www.freedesktop.org/wiki/Software/systemd/json

Ü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 <debian-l10n-german@lists.debian.org>.