DOKK / manpages / debian 12 / manpages-de / systemd-coredump.8.de
SYSTEMD-COREDUMP(8) systemd-coredump SYSTEMD-COREDUMP(8)

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

ÜBERSICHT

/lib/systemd/systemd-coredump

/lib/systemd/systemd-coredump --backtrace

systemd-coredump@.service

systemd-coredump.socket

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.

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[1]. 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.

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[2].

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.

Um die möglicherweise ressourcenintensive Verarbeitung durch systemd-coredump zu deaktivieren, setzen Sie

Storage=none ProcessSizeMax=0

in coredump.conf(5).

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=/lib64/firefox/firefox
COREDUMP_USER_UNIT=app-gnome-firefox-552136.scope
COREDUMP_CMDLINE=/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.

COREDUMP_TIMESTAMP=

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

COREDUMP_RLIMIT=

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

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.

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

COREDUMP_OWNER_UID=, COREDUMP_USER_UNIT=

Die numerische UID des Benutzers, dem die Anmeldesitzung oder die Systemd-Benutzer-Unit des abgestürzten Prozesses gehört, und die Benutzerverwalter-Unit. Beide 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.

COREDUMP_SIGNAL_NAME=, COREDUMP_SIGNAL=

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

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.

COREDUMP_OPEN_FDS=

Informationen über offene Dateideskriptoren, in den folgenden Formaten: 

fd:/Pfad/zur/Datei
pos:     …
flags:   …
…
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.

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.

COREDUMP_COMM=, COREDUMP_PROC_STATUS=, COREDUMP_PROC_MAPS=, COREDUMP_PROC_LIMITS=, COREDUMP_PROC_MOUNTINFO=, COREDUMP_ENVIRON=

Felder, die die prozessbezogenen Einträge im Dateisystem /proc zuordnen: /proc/PID/comm (der dem Prozess zugeordnete Befehlsname), /proc/PID/exe (der Dateiname des ausgeführten Befehls), /proc/PID/status (verschiedene Metadaten des Prozesses), /proc/PID/maps (Speicherregionen, die für den Prozess sichtbar sind und die zugehörigen Zugriffsberechtigungen), /proc/PID/limits (die weichen und die harten Speicherbegrenzungen), /proc/PID/mountinfo (Einhängepunkte im Einhängenamensraum des Prozesses), /proc/PID/environ (der Umgebungsblock des abgestürzten Prozesses).

Siehe proc(5) für weitere Informationen.

COREDUMP_HOSTNAME=

Der System-Rechnername.

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

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

COREDUMP=

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

COREDUMP_FILENAME=

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

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

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[4].

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.

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

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="/lib64/firefox/firefox"
…

coredump.conf(5), coredumpctl(1), systemd-journald.service(8), systemd-tmpfiles(8), core(5), sysctl.d(5), systemd-sysctl.service(8).

1.
Journal-Exportformat
https://systemd.io/JOURNAL_EXPORT_FORMATS#journal-export-format
2.
systemd-coredump-python
https://github.com/systemd/systemd-coredump-python
3.
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.
4.
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 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.

systemd 252