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

       /lib/systemd/systemd-coredump

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

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

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

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

SIEHE AUCH

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

ANMERKUNGEN

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