Ubuntu Manpage: systemd-coredump, systemd-coredump.socket, systemd-coredump@.service

BEZEICHNUNG

       systemd-coredump, systemd-coredump.socket, systemd-coredump@.service - Erlangen, Speichern
       und Verarbeiten von Speicherauszügen

ÜBERSICHT

       /usr/lib/systemd/systemd-coredump

       /usr/lib/systemd/systemd-coredump --backtrace

       systemd-coredump@.service

       systemd-coredump.socket

BESCHREIBUNG

systemd-coredump@.service ist ein System-Dienst, um Speicherauszüge zu verarbeiten. Es
wird eine Zusammenfassung der Ereignisse nach systemd-journald.service(8) protokollieren,
einschließlich Informationen über den Prozesskennzeichner, Eigentümer, das Signal, das den
Prozess tötete und (falls möglich) die Stack-Ablaufverfolgung (»Stack-Trace«). Es kann die
Speicherauszüge auch für eine spätere Verarbeitung speichern. Siehe den nachfolgenden
Abschnitt »Informationen über abgestürzte Prozesse«.

Das Verhalten eines bestimmten Programms beim Empfang eines Signal wird durch zwei
Faktoren geregelt, die in core(5) im Detail beschrieben sind. Insbesondere werden
Speicherauszüge nur verarbeitet, wenn die zugehörigen Ressourcenbegrenzungen ausreichend
sind.

Speicherauszüge können in das Journal geschrieben oder als Datei gespeichert werden. In
beiden Fällen können sie für weitere Verarbeitungen, beispielsweise in gdb(1), abgefragt
werden. Siehe coredumpctl(1), insbesondere die Verben list und debug.

Standardmäßig protokolliert systemd-coredump den Speicherauszug in das Journal,
einschließlich (falls möglich) einer Ablaufverfolgung (Backtrace) und speichert den
Speicherauszug (ein Abbild der Speicherinhalte des Prozesses) selbst in einer externen
Datei in /var/lib/systemd/coredump. Diese Speicherauszüge werden nach ein paar Tagen
standardmäßig gelöscht; siehe /usr/lib/tmpfiles.d/systemd.conf für Details. Beachten Sie,
dass die Entfernung von Speicherauszugsdateien aus dem Dateisystem und das Entfernen der
Journal-Einträge voneinander unabhängig sind, und die Speicherauszugsdatei ohne den
Journal-Eintrag vorhanden sein kann und Journal-Einträge auf bereits entfernte
Speicherauszugsdateien verweisen können. Einige Metadaten werden an die
Speicherauszugsdateien in Form von erweiterten Attributen angehängt, so dass die
Speicherauszugsdateien für einige Zwecke selbst ohne die vollständigen Metadaten im
Journal-Eintrag nützlich sein können.

Für weitere Details siehe Systemd-Speicherauszug-Handhabung[1].

Aufruf von systemd-coredump
Das Programm systemd-coredump erledigt die eigentliche Arbeit. Es wird zweimal aufgerufen:
einmal als Handhabungsprogramm durch den Kernel und das zweite Mal in
systemd-coredump@.service, um die Daten tatsächlich ins Journal zu schreiben und die
Speicherauszugsdateien zu verarbeiten und zu speichern.

Wenn der Kernel systemd-coredump aufruft, um den Speicherauszug zu handhaben, läuft es im
privilegierten Modus und wird sich mit dem durch die Unit systemd-coredump.socket
erstellten Socket verbinden, die wiederum eine nicht privilegierte
systemd-coredump@.service-Instanz erzeugen wird, um den Speicherauzug zu verarbeiten.
Daher sind systemd-coredump.socket und systemd-coredump@.service Hilfs-Units, die die
eigentliche Verarbeitung von Speicherauszügen vornehmen und der normalen Diensteverwaltung
unterliegen.

Es ist auch möglich, systemd-coredump mit der Option --backtrace aufzurufen. In diesem
Fall erwartet systemd-coredump auf der Standardeingabe einen Journaleintrag im
Journal-Exportformat[2]. Der Eintrag sollte ein MESSAGE=-Feld und sämtliche zusätzliche
Metadatenfelder, die der Aufrufende vernünftigerweise erwarten würde, enthalten.
systemd-coredump hängt zusätzliche Metadatenfelder auf die gleiche Art an, wie es das für
vom Kernel empfangene Speicherauszüge auch macht. In diesem Modus werden keine
Speicherauszüge im Journal gespeichert.

KONFIGURATION

Für von systemd gestartete Programme können Prozessressourcenbegrenzungen mit der
Direktive LimitCORE= eingerichtet werden, siehe systemd.exec(5).

Um vom Kernel für den Umgang mit Speicherauszügen eingesetzt zu werden, muss
systemd-coredump im Parameter kernel.core_pattern von sysctl(8) konfiguriert sein. Die
Syntax dieses Parameters wird in core(5) erklärt. Systemd installiert die Datei
/usr/lib/sysctl.d/50-coredump.conf, die kernel.core_pattern entsprechend konfiguriert.
Diese Datei kann gemäß normaler sysctl.d(5)-Regeln maskiert oder außer Kraft gesetzt
werden, um eine andere Einstellung zu verwenden. Falls die Sysctl-Konfiguration verändert
wird, muss diese im Kernel aktualisiert werden, bevor sie wirksam wird, siehe sysctl(8)
und systemd-sysctl(8).

Um im Modus --backtrace eingesetzt zu werden, muss ein geeignetes
Backtrace-Handhabungsprogramm auf der Senderseite installiert sein. Im Falle von python(1)
bedeutet dies beispielsweise, dass ein sys.excepthook installiert sein muss, siehe
systemd-coredump-python[3].

Das Verhalten von systemd-coredump selbst wird mittels der Konfigurationsdatei
/etc/systemd/coredump.conf und entsprechenden Schnippseln in
/etc/systemd/coredump.conf.d/*.conf konfiguriert, siehe coredump.conf(5). Eine neue
Instanz von systemd-coredump wird nach jedem Empfang eines Speicherauszuges aufgerufen.
Daher werden Änderungen in diesen Dateien wirksam, wenn das nächste Mal ein Speicherauszug
empfangen wird.

Die von Speicherauszügen verwandten Ressourcen werden auf zwei Arten begrenzt. Parameter
wie die maximale Größe empfangener Speicherauszüge und Dateien können in den oben
erwähnten Dateien /etc/systemd/coredump.conf und Schnippseln geändert werden. Zusätzlich
wird die Speicherdauer von Speicherauszügen durch systemd-tmpfiles beschränkt,
entsprechende Einstellungen sind standardmäßig in /usr/lib/tmpfiles.d/systemd.conf.
Standardmäßig werden die Speicherauszüge nach ein paar Tagen gelöscht; weitere Details
finden Sie in obiger Datei.

Deaktivierung der Verarbeitung von Speicherauszügen
Um die möglicherweise ressourcenintensive Verarbeitung durch systemd-coredump zu
deaktivieren, setzen Sie

Storage=none
ProcessSizeMax=0

in coredump.conf(5).

INFORMATIONEN ÜBER ABGESTÜRZTE PROZESSE

coredumpctl(1) kann zur Abfrage gespeicherter Speicherauszüge, unabhängig von ihrem Ort,
zur Anzeige von Informationen und zur Verarbeitung z.B. durch Weitergabe an den
GNU-Debugger (gdb) verwandt werden.

Im Journal gespeicherte Daten können auch wie gewöhnlich mit journalctl(1) (oder von einem
anderen Prozess mittels der sd-journal(3)-API) betrachtet werden. Die relevanten
Nachrichten enthalten MESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1:

$ journalctl MESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1 -o verbose
…
MESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1
COREDUMP_PID=552351
COREDUMP_UID=1000
COREDUMP_GID=1000
COREDUMP_SIGNAL_NAME=SIGSEGV
COREDUMP_SIGNAL=11
COREDUMP_TIMESTAMP=1614342930000000
COREDUMP_COMM=Web Content
COREDUMP_EXE=/usr/lib64/firefox/firefox
COREDUMP_USER_UNIT=app-gnome-firefox-552136.scope
COREDUMP_CMDLINE=/usr/lib64/firefox/firefox -contentproc -childID 5 -isForBrowser …
COREDUMP_CGROUP=/user.slice/user-1000.slice/user@1000.service/app.slice/app-….scope
COREDUMP_FILENAME=/var/lib/systemd/coredump/core.Web….552351.….zst
…

Die folgenden Felder werden (falls bekannt) mit dem Journal-Eintrag gespeichert:

COREDUMP_UID=, COREDUMP_PID=, COREDUMP_GID=
Die Prozessnummer (PID), die Benutzernummer (UID) und die Gruppennummer (GID) des
Eigentümers des abgestürzten Prozesses.

Falls der abgestürzte Prozess Teil eines Containers war (oder im allgemeinen in einem
Prozess- oder Benutzernamensraum war), sind dies die von außen gesehenen Werte, im
Namensraum, in dem systemd-coredump läuft.

Hinzugefügt in Version 248.

COREDUMP_TIMESTAMP=
Die Uhrzeit vom Absturz, wie vom Kernel gemeldet (in µs seit der Epoch).

Hinzugefügt in Version 248.

COREDUMP_RLIMIT=
Die weiche Ressourcenbegrenzung für Speicherauszugsdateien, siehe getrlimit(2).

Hinzugefügt in Version 248.

COREDUMP_UNIT=, COREDUMP_SLICE=
Die Namen der System-Unit und der Scheibe.

Wenn der abgestürzte Prozess sich in einem Container befand, sind dies die Unit-Namen
außerhalb, im Haupt-Systemverwalter.

Hinzugefügt in Version 248.

COREDUMP_CGROUP=
Die primäre Cgrup der Unit des abgestürzten Prozesses.

Wenn der abgestürzte Prozess sich in einem Container befand, ist dies der vollständige
Pfad, wie er außerhalb des Containers gesehen wird.

Hinzugefügt in Version 248.

COREDUMP_PROC_CGROUP=
Control-Gruppen-Informationen in dem Format, das in /proc/self/cgroup genutzt wird.
Auf Systemen mit vereinigter Cgroup-Hierarchie, ist dies der einzelne Pfad, dem »0::«
vorangestellt wurde, und mehrere Pfade, denen die Controller-Nummer vorangestellt
wurden, auf Altsystemen.

Wenn der abgestürzte Prozess sich in einem Container befand, ist dies der vollständige
Pfad, wie er außerhalb des Containers gesehen wird.

Hinzugefügt in Version 248.

COREDUMP_OWNER_UID=, COREDUMP_USER_UNIT=, COREDUMP_SESSION=
Die numerische UID des Benutzers, dem die Anmeldesitzung oder die
Systemd-Benutzer-Unit des abgestürzten Prozesses gehört, die Benutzerverwalter-Unit
und den Sitzungskennzeichner. Alle drei Felder sind nur für Benutzerprozesse
vorhanden.

Wenn sich der abgestürzte Prozess in einem Container befand, sind dies die Werte
außerhalb, im Hauptsystem.

Hinzugefügt in Version 248.

COREDUMP_SIGNAL_NAME=, COREDUMP_SIGNAL=
Der Name des beendenden Signals (mit »SIG« am Anfang [4]) und der numerische Wert.
(Beide sind enthalten, da sich die Signalnummern zwischen Architekturen
unterscheiden.)

Hinzugefügt in Version 248.

COREDUMP_CWD=, COREDUMP_ROOT=
Das aktuelle Arbeitsverzeichnis und Wurzelverzeichnis des abgestürzten Prozesses.

Wenn sich der abgestürzte Prozess in einem Container befand, sind diese Pfade relativ
zur Wurzel des Einhängenamensraums des Containers.

Hinzugefügt in Version 248.

COREDUMP_OPEN_FDS=
Informationen über offene Dateideskriptoren, in den folgenden Formaten:

fd:/Pfad/zur/Datei
pos: …
flags: …
…

Die erste Zeile enthält die Dateideskriptorennummer fd und den Pfad, während
nachfolgende Zeilen die Inhalte von /proc/PID/fdinfo/fd anzeigen.

Hinzugefügt in Version 248.

COREDUMP_EXE=
Das Ziel des Symlinks /proc/PID/exe.

Wenn sich der abgestürzte Prozess in einem Container befindet, ist der Pfad relativ zu
der Wurzel des Einhängenamensraums des Containers.

Hinzugefügt in Version 248.

COREDUMP_CMDLINE=, COREDUMP_COMM=, COREDUMP_ENVIRON=, COREDUMP_PROC_AUXV=,
COREDUMP_PROC_LIMITS=, COREDUMP_PROC_MAPS=, COREDUMP_PROC_MOUNTINFO=,
COREDUMP_PROC_STATUS=
Felder, die die prozessbezogenen Einträge im Dateisystem /proc zuordnen:
/proc/PID/cmdline (die Befehlszeile des abgestürzten Prozesses), /proc/PID/comm (der
dem Prozess zugeordnete Befehlsname), /proc/PID/environ (der Umgebungsblock des
abgestürzten Prozesses), /proc/PID/auxv (der Hilfsvektor des abgestürzten Prozesses,
siehe getauxval(3)), /proc/PID/limits (die weichen und die harten
Ressourcenbegrenzungen), /proc/PID/maps (Speicherregionen, die für den Prozess
sichtbar sind und die zugehörigen Zugriffsberechtigungen), /proc/PID/mountinfo
(Einhängepunkte im Einhängenamensraum des Prozesses), /proc/PID/status (verschiedene
Metadaten des Prozesses).

Siehe proc(5) für weitere Informationen.

Hinzugefügt in Version 248.

COREDUMP_HOSTNAME=
Der System-Rechnername.

Wenn sich der abgestürzte Prozess in einem Container befand, ist dies der Rechnername
des Containers.

Hinzugefügt in Version 248.

COREDUMP_CONTAINER_CMDLINE=
Für Prozesse, die in einem Container ausgeführt werden, die Befehlszeile des
Prozesses, der den Container gestartet hat (der erste übergeordnete Prozess mit einem
anderen Einhängenamensraum).

Hinzugefügt in Version 248.

COREDUMP=
Wenn der Speicherauszug im Journal gespeichert wurde, das Speicherauszugsabbild
selbst.

Hinzugefügt in Version 248.

COREDUMP_FILENAME=
Wenn der Speicherauszug extern gespeichert wurde, der Pfad zu der
Speicherauszugsdatei.

Hinzugefügt in Version 248.

COREDUMP_TRUNCATED=
Auf »1« gesetzt, wenn der gespeicherte Speicherauszug abgeschnitten wurde. (Eine
unvollständige Speicherauszugsdatei kann von einigen Werkzeugen noch verarbeitet
werden, obwohl logischerweise nicht die vollständigen Informationen vorhanden sind.)

Hinzugefügt in Version 248.

COREDUMP_PACKAGE_NAME=, COREDUMP_PACKAGE_VERSION=, COREDUMP_PACKAGE_JSON=
Falls das Programm .package-Metadaten-ELF-Bemerkungen enthält, werden diese
ausgewertet und angehängt. Das Paket und die PaketVersion des
[u00BB]Haupt[u00AB]-ELF-Moduls (d.h. des Programms) werden einzeln angehängt. Der
JSON-formatierte Inhalt aller Module wird als einzelnes JSON-Objekt angehängt, jedes
mit dem Modulnamen als Schlüssel. Für weitere Informationen über dieses
Metadatenformat und den Inhalt, siehe die Speicherauszugs-Metadatenspezifikation[5].

Hinzugefügt in Version 249.

MESSAGE=
Die durch systemd-coredump erstellte Nachricht, die die Ablaufverfolgung enthält,
falls sie erfolgreich erstellt wurde. Wird systemd-coredump mit --backtrace
aufgerufen, dann wird das Feld vom Aufrufenden bereitgestellt.

Hinzugefügt in Version 248.

Im Journal-Eintrag existieren eine Reihe von weiteren Feldern, die aber dem
Protokollierungsprozess betreffen, d.h. systemd-coredump und nicht den abgestürzten
Prozess. Siehe systemd.journal-fields(7).

Die folgenden Felder werden mit der in COREDUMP_FILENAME= aufgeführten externen Datei als
erweiterte Attribute gespeichert (falls bekannt):

user.coredump.pid, user.coredump.uid, user.coredump.gid, user.coredump.signal,
user.coredump.timestamp, user.coredump.rlimit, user.coredump.hostname, user.coredump.comm,
user.coredump.exe
Diese sind identisch zu den oben beschriebenen COREDUMP_PID=, COREDUMP_UID=,
COREDUMP_GID=, COREDUMP_SIGNAL=, COREDUMP_TIMESTAMP=, COREDUMP_RLIMIT=,
COREDUMP_HOSTNAME=, COREDUMP_COMM= und COREDUMP_EXE=.

Hinzugefügt in Version 248.

Diese können sich mittels getfattr(1) angeschaut werden. Für die im obigen Journal-Eintrag
gezeigte Speicherauszugsdatei:

$ getfattr --absolute-names -d /var/lib/systemd/coredump/core.Web….552351.….zst
# file: /var/lib/systemd/coredump/core.Web….552351.….zst
user.coredump.pid="552351"
user.coredump.uid="1000"
user.coredump.gid="1000"
user.coredump.signal="11"
user.coredump.timestamp="1614342930000000"
user.coredump.comm="Web Content"
user.coredump.exe="/usr/lib64/firefox/firefox"
…

SIEHE AUCH

       coredump.conf(5), coredumpctl(1), systemd-journald.service(8), systemd-tmpfiles(8),
       core(5), sysctl.d(5), systemd-sysctl.service(8), Systemd-Speicherauszug-Handhabung[1]

ANMERKUNGEN

        1. Systemd-Speicherauszug-Handhabung
           https://systemd.io/COREDUMP

        2. Journal-Exportformat
           https://systemd.io/JOURNAL_EXPORT_FORMATS#journal-export-format

        3. systemd-coredump-python
           https://github.com/systemd/systemd-coredump-python

        4. kill(1) erwartet Signalnamen ohne den Präfix; kill(2) verwendet den Präfix; alle
           Systemd-Werkzeuge akzeptieren Signalnamen sowohl ohne als auch mit dem Präfix.

        5. Die Speicherauszugs-Metadatenspezifikation
           https://systemd.io/COREDUMP_PACKAGE_METADATA/

Ü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 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ 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 ⟨debian-l10n-german@lists.debian.org⟩.