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

bezeichnung
übersicht
beschreibung
konfiguration
informationen über abgestürzte prozesse
siehe auch
anmerkungen
übersetzung

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