- bookworm 4.18.1-1
- bookworm-backports 4.24.0-2~bpo12+1
- testing 4.24.0-2
- unstable 4.24.0-2
SYSTEMD-COREDUMP(8) | systemd-coredump | SYSTEMD-COREDUMP(8) |
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.
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=/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=
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=
COREDUMP_RLIMIT=
COREDUMP_UNIT=, COREDUMP_SLICE=
Wenn der abgestürzte Prozess sich in einem Container befand, sind dies die Unit-Namen außerhalb, im Haupt-Systemverwalter.
COREDUMP_CGROUP=
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_PROC_CGROUP=
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=, COREDUMP_SESSION=
Wenn sich der abgestürzte Prozess in einem Container befand, sind dies die Werte außerhalb, im Hauptsystem.
COREDUMP_SIGNAL_NAME=, COREDUMP_SIGNAL=
COREDUMP_CWD=, COREDUMP_ROOT=
Wenn sich der abgestürzte Prozess in einem Container befand, sind diese Pfade relativ zur Wurzel des Einhängenamensraums des Containers.
COREDUMP_OPEN_FDS=
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=
Wenn sich der abgestürzte Prozess in einem Container befindet, ist der Pfad relativ zu der Wurzel des Einhängenamensraums des Containers.
COREDUMP_CMDLINE=, COREDUMP_COMM=, COREDUMP_ENVIRON=, COREDUMP_PROC_AUXV=, COREDUMP_PROC_LIMITS=, COREDUMP_PROC_MAPS=, COREDUMP_PROC_MOUNTINFO=, COREDUMP_PROC_STATUS=
Siehe proc(5) für weitere Informationen.
COREDUMP_HOSTNAME=
Wenn sich der abgestürzte Prozess in einem Container befand, ist dies der Rechnername des Containers.
COREDUMP_CONTAINER_CMDLINE=
COREDUMP=
COREDUMP_FILENAME=
COREDUMP_TRUNCATED=
COREDUMP_PACKAGE_NAME=, COREDUMP_PACKAGE_VERSION=, COREDUMP_PACKAGE_JSON=
MESSAGE=
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 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), Systemd-Speicherauszug-Handhabung[1]
ANMERKUNGEN¶
- 1.
- Systemd-Speicherauszug-Handhabung
- 2.
- Journal-Exportformat
- 3.
- 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
Ü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 254 |