Provided by: manpages-de_4.21.0-2_all bug

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=
           The primary cgroup of the unit of the crashed process.

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

               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=
           Fields that map the per-process entries in the /proc/ filesystem: /proc/pid/cmdline
           (the command line of the crashed process), /proc/pid/comm (the command name associated
           with the process), /proc/pid/environ (the environment block of the crashed process),
           /proc/pid/auxv (the auxiliary vector of the crashed process, see getauxval(3)),
           /proc/pid/limits (the soft and hard resource limits), /proc/pid/maps (memory regions
           visible to the process and their access permissions), /proc/pid/mountinfo (mount
           points in the process's mount namespace), /proc/pid/status (various metadata about the
           process).

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