.\" -*- coding: UTF-8 -*- '\" t .\"******************************************************************* .\" .\" This file was generated with po4a. Translate the source file. .\" .\"******************************************************************* .TH SYSTEMD\-COREDUMP 8 "" "systemd 252" systemd\-coredump .ie \n(.g .ds Aq \(aq .el .ds Aq ' .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .\" http://bugs.debian.org/507673 .\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html .\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .\" ----------------------------------------------------------------- .\" * set default formatting .\" ----------------------------------------------------------------- .\" disable hyphenation .nh .\" disable justification (adjust text to left margin only) .ad l .\" ----------------------------------------------------------------- .\" * MAIN CONTENT STARTS HERE * .\" ----------------------------------------------------------------- .SH BEZEICHNUNG systemd\-coredump, systemd\-coredump.socket, systemd\-coredump@.service \- Erlangen, Speichern und Verarbeiten von Speicherauszügen .SH ÜBERSICHT .PP /lib/systemd/systemd\-coredump .PP /lib/systemd/systemd\-coredump \fB\-\-backtrace\fP .PP systemd\-coredump@\&.service .PP systemd\-coredump\&.socket .SH BESCHREIBUNG .PP systemd\-coredump@\&.service ist ein System\-Dienst, um Speicherauszüge zu verarbeiten\&. Es wird eine Zusammenfassung der Ereignisse nach \fBsystemd\-journald.service\fP(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«\&. .PP Das Verhalten eines bestimmten Programms beim Empfang eines Signal wird durch zwei Faktoren geregelt, die in \fBcore\fP(5) im Detail beschrieben sind\&. Insbesondere werden Speicherauszüge nur verarbeitet, wenn die zugehörigen Ressourcenbegrenzungen ausreichend sind\&. .PP 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 \fBgdb\fP(1), abgefragt werden\&. Siehe \fBcoredumpctl\fP(1), insbesondere die Verben \fBlist\fP und \fBdebug\fP\&. .PP Standardmäßig protokolliert \fBsystemd\-coredump\fP 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\&. .SS "Aufruf von systemd\-coredump" .PP Das Programm \fBsystemd\-coredump\fP 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\&. .PP Wenn der Kernel \fBsystemd\-coredump\fP 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\&. .PP Es ist auch möglich, \fBsystemd\-coredump\fP mit der Option \fB\-\-backtrace\fP aufzurufen\&. In diesem Fall erwartet \fBsystemd\-coredump\fP auf der Standardeingabe einen Journaleintrag im \m[blue]\fBJournal\-Exportformat\fP\m[]\&\s-2\u[1]\d\s+2\&. Der Eintrag sollte ein \fIMESSAGE=\fP\-Feld und sämtliche zusätzliche Metadatenfelder, die der Aufrufende vernünftigerweise erwarten würde, enthalten\&. \fBsystemd\-coredump\fP 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\&. .SH KONFIGURATION .PP Für von \fBsystemd\fP gestartete Programme können Prozessressourcenbegrenzungen mit der Direktive \fILimitCORE=\fP eingerichtet werden, siehe \fBsystemd.exec\fP(5)\&. .PP Um vom Kernel für den Umgang mit Speicherauszügen eingesetzt zu werden, muss \fBsystemd\-coredump\fP im Parameter \fIkernel\&.core_pattern\fP von \fBsysctl\fP(8) konfiguriert sein\&. Die Syntax dieses Parameters wird in \fBcore\fP(5) erklärt\&. Systemd installiert die Datei /usr/lib/sysctl\&.d/50\-coredump\&.conf, die \fIkernel\&.core_pattern\fP entsprechend konfiguriert\&. Diese Datei kann gemäß normaler \fBsysctl.d\fP(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 \fBsysctl\fP(8) und \fBsystemd\-sysctl\fP(8)\&. .PP Um im Modus \fB\-\-backtrace\fP eingesetzt zu werden, muss ein geeignetes Backtrace\-Handhabungsprogramm auf der Senderseite installiert sein\&. Im Falle von \fBpython\fP(1) bedeutet dies beispielsweise, dass ein \fIsys\&.excepthook\fP installiert sein muss, siehe \m[blue]\fBsystemd\-coredump\-python\fP\m[]\&\s-2\u[2]\d\s+2\&. .PP Das Verhalten von \fBsystemd\-coredump\fP selbst wird mittels der Konfigurationsdatei /etc/systemd/coredump\&.conf und entsprechenden Schnippseln in /etc/systemd/coredump\&.conf\&.d/*\&.conf konfiguriert, siehe \fBcoredump.conf\fP(5)\&. Eine neue Instanz von \fBsystemd\-coredump\fP wird nach jedem Empfang eines Speicherauszuges aufgerufen\&. Daher werden Änderungen in diesen Dateien wirksam, wenn das nächste Mal ein Speicherauszug empfangen wird\&. .PP 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 \fBsystemd\-tmpfiles\fP 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\&. .SS "Deaktivierung der Verarbeitung von Speicherauszügen" .PP Um die möglicherweise ressourcenintensive Verarbeitung durch \fBsystemd\-coredump\fP zu deaktivieren, setzen Sie .sp .if n \{\ .RS 4 .\} .nf Storage=none ProcessSizeMax=0 .fi .if n \{\ .RE .\} .sp in \fBcoredump.conf\fP(5)\&. .SH "INFORMATIONEN ÜBER ABGESTÜRZTE PROZESSE" .PP \fBcoredumpctl\fP(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\&. .PP Im Journal gespeicherte Daten können auch wie gewöhnlich mit \fBjournalctl\fP(1) (oder von einem anderen Prozess mittels der \fBsd\-journal\fP(3)\-API) betrachtet werden\&. Die relevanten Nachrichten enthalten \fBMESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1\fP: .sp .if n \{\ .RS 4 .\} .nf $ 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 … .fi .if n \{\ .RE .\} .PP Die folgenden Felder werden (falls bekannt) mit dem Journal\-Eintrag gespeichert: .PP \fICOREDUMP_UID=\fP, \fICOREDUMP_PID=\fP, \fICOREDUMP_GID=\fP .RS 4 Die Prozessnummer (PID), die Benutzernummer (UID) und die Gruppennummer (GID) des Eigentümers des abgestürzten Prozesses\&. .sp Falls der abgestürzte Prozess Teil eines Containers war (oder im allgemeinen in einem Prozess\- oder Benutzernamensraum war), sind dies die von \fIaußen\fP gesehenen Werte, im Namensraum, in dem systemd\-coredump läuft\&. .RE .PP \fICOREDUMP_TIMESTAMP=\fP .RS 4 Die Uhrzeit vom Absturz, wie vom Kernel gemeldet (in \(mcs seit der Epoch)\&. .RE .PP \fICOREDUMP_RLIMIT=\fP .RS 4 Die weiche Ressourcenbegrenzung für Speicherauszugsdateien, siehe \fBgetrlimit\fP(2)\&. .RE .PP \fICOREDUMP_UNIT=\fP, \fICOREDUMP_SLICE=\fP .RS 4 Die Namen der System\-Unit und der Scheibe\&. .sp Wenn der abgestürzte Prozess sich in einem Container befand, sind dies die Unit\-Namen \fIaußerhalb\fP, im Haupt\-Systemverwalter\&. .RE .PP \fICOREDUMP_CGROUP=\fP .RS 4 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\&. .sp Wenn der abgestürzte Prozess sich in einem Container befand, ist dies der vollständige Pfad, wie er außerhalb des Containers gesehen wird\&. .RE .PP \fICOREDUMP_OWNER_UID=\fP, \fICOREDUMP_USER_UNIT=\fP .RS 4 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\&. .sp Wenn sich der abgestürzte Prozess in einem Container befand, sind dies die Werte \fIaußerhalb\fP, im Hauptsystem\&. .RE .PP \fICOREDUMP_SIGNAL_NAME=\fP, \fICOREDUMP_SIGNAL=\fP .RS 4 Der Name des beendenden Signals (mit »SIG« am Anfang \&\s-2\u[3]\d\s+2) und der numerische Wert\&. (Beide sind enthalten, da sich die Signalnummern zwischen Architekturen unterscheiden\&.) .RE .PP \fICOREDUMP_CWD=\fP, \fICOREDUMP_ROOT=\fP .RS 4 Das aktuelle Arbeitsverzeichnis und Wurzelverzeichnis des abgestürzten Prozesses\&. .sp Wenn sich der abgestürzte Prozess in einem Container befand, sind diese Pfade relativ zur Wurzel des Einhängenamensraums des Containers\&. .RE .PP \fICOREDUMP_OPEN_FDS=\fP .RS 4 Informationen über offene Dateideskriptoren, in den folgenden Formaten: .sp .if n \{\ .RS 4 .\} .nf \fIfd\fP:\fI/Pfad/zur/Datei\fP pos: … flags: … … \fIfd\fP:\fI/Pfad/zur/Datei\fP pos: … flags: … … .fi .if n \{\ .RE .\} .sp Die erste Zeile enthält die Dateideskriptorennummer \fIfd\fP und den Pfad, während nachfolgende Zeilen die Inhalte von /proc/\fIPID\fP/fdinfo/\fIfd\fP anzeigen\&. .RE .PP \fICOREDUMP_EXE=\fP .RS 4 Das Ziel des Symlinks /proc/\fIPID\fP/exe\&. .sp Wenn sich der abgestürzte Prozess in einem Container befindet, ist der Pfad relativ zu der Wurzel des Einhängenamensraums des Containers\&. .RE .PP \fICOREDUMP_COMM=\fP, \fICOREDUMP_PROC_STATUS=\fP, \fICOREDUMP_PROC_MAPS=\fP, \fICOREDUMP_PROC_LIMITS=\fP, \fICOREDUMP_PROC_MOUNTINFO=\fP, \fICOREDUMP_ENVIRON=\fP .RS 4 Felder, die die prozessbezogenen Einträge im Dateisystem /proc zuordnen: /proc/\fIPID\fP/comm (der dem Prozess zugeordnete Befehlsname), /proc/\fIPID\fP/exe (der Dateiname des ausgeführten Befehls), /proc/\fIPID\fP/status (verschiedene Metadaten des Prozesses), /proc/\fIPID\fP/maps (Speicherregionen, die für den Prozess sichtbar sind und die zugehörigen Zugriffsberechtigungen), /proc/\fIPID\fP/limits (die weichen und die harten Speicherbegrenzungen), /proc/\fIPID\fP/mountinfo (Einhängepunkte im Einhängenamensraum des Prozesses), /proc/\fIPID\fP/environ (der Umgebungsblock des abgestürzten Prozesses)\&. .sp Siehe \fBproc\fP(5) für weitere Informationen. .RE .PP \fICOREDUMP_HOSTNAME=\fP .RS 4 Der System\-Rechnername\&. .sp Wenn sich der abgestürzte Prozess in einem Container befand, ist dies der Rechnername des Containers\&. .RE .PP \fICOREDUMP_CONTAINER_CMDLINE=\fP .RS 4 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)\&. .RE .PP \fICOREDUMP=\fP .RS 4 Wenn der Speicherauszug im Journal gespeichert wurde, das Speicherauszugsabbild selbst\&. .RE .PP \fICOREDUMP_FILENAME=\fP .RS 4 Wenn der Speicherauszug extern gespeichert wurde, der Pfad zu der Speicherauszugsdatei\&. .RE .PP \fICOREDUMP_TRUNCATED=\fP .RS 4 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\&.) .RE .PP \fICOREDUMP_PACKAGE_NAME=\fP, \fICOREDUMP_PACKAGE_VERSION=\fP, \fICOREDUMP_PACKAGE_JSON=\fP .RS 4 Falls das Programm \&.package\-Metadaten\-ELF\-Bemerkungen enthält, werden diese ausgewertet und angehängt\&. Das \fIPaket\fP und die \fIPaketVersion\fP des \*»Haupt\*«\-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 \m[blue]\fBdie Speicherauszugs\-Metadatenspezifikation\fP\m[]\&\s-2\u[4]\d\s+2\&. .RE .PP \fIMESSAGE=\fP .RS 4 Die durch \fBsystemd\-coredump\fP erstellte Nachricht, die die Ablaufverfolgung enthält, falls sie erfolgreich erstellt wurde\&. Wird \fBsystemd\-coredump\fP mit \fB\-\-backtrace\fP aufgerufen, dann wird das Feld vom Aufrufenden bereitgestellt\&. .RE .PP Im Journal\-Eintrag existieren eine Reihe von weiteren Feldern, die aber dem Protokollierungsprozess betreffen, d\&.h\&. \fBsystemd\-coredump\fP und nicht den abgestürzten Prozess\&. Siehe \fBsystemd.journal\-fields\fP(7)\&. .PP Die folgenden Felder werden mit der in \fICOREDUMP_FILENAME=\fP aufgeführten externen Datei als erweiterte Attribute gespeichert (falls bekannt): .PP \fIuser\&.coredump\&.pid\fP, \fIuser\&.coredump\&.uid\fP, \fIuser\&.coredump\&.gid\fP, \fIuser\&.coredump\&.signal\fP, \fIuser\&.coredump\&.timestamp\fP, \fIuser\&.coredump\&.rlimit\fP, \fIuser\&.coredump\&.hostname\fP, \fIuser\&.coredump\&.comm\fP, \fIuser\&.coredump\&.exe\fP .RS 4 Diese sind identisch zu den oben beschriebenen \fICOREDUMP_PID=\fP, \fICOREDUMP_UID=\fP, \fICOREDUMP_GID=\fP, \fICOREDUMP_SIGNAL=\fP, \fICOREDUMP_TIMESTAMP=\fP, \fICOREDUMP_RLIMIT=\fP, \fICOREDUMP_HOSTNAME=\fP, \fICOREDUMP_COMM=\fP und \fICOREDUMP_EXE=\fP\&. .RE .PP Diese können sich mittels \fBgetfattr\fP(1) angeschaut werden\&. Für die im obigen Journal\-Eintrag gezeigte Speicherauszugsdatei: .sp .if n \{\ .RS 4 .\} .nf $ 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" … .fi .if n \{\ .RE .\} .sp .SH "SIEHE AUCH" .PP \fBcoredump.conf\fP(5), \fBcoredumpctl\fP(1), \fBsystemd\-journald.service\fP(8), \fBsystemd\-tmpfiles\fP(8), \fBcore\fP(5), \fBsysctl.d\fP(5), \fBsystemd\-sysctl.service\fP(8)\&. .SH ANMERKUNGEN .IP " 1." 4 Journal\-Exportformat .RS 4 \%https://systemd.io/JOURNAL_EXPORT_FORMATS#journal\-export\-format .RE .IP " 2." 4 systemd\-coredump\-python .RS 4 \%https://github.com/systemd/systemd\-coredump\-python .RE .IP " 3." 4 \fBkill\fP(1) erwartet Signalnamen \fIohne\fP den Präfix; \fBkill\fP(2) verwendet den Präfix; alle Systemd\-Werkzeuge akzeptieren Signalnamen sowohl ohne als auch mit dem Präfix. .IP " 4." 4 Die Speicherauszugs\-Metadatenspezifikation .RS 4 \%https://systemd.io/COREDUMP_PACKAGE_METADATA/ .RE .PP .SH ÜBERSETZUNG Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann erstellt. .PP Diese Übersetzung ist Freie Dokumentation; lesen Sie die .UR https://www.gnu.org/licenses/gpl-3.0.html GNU General Public License Version 3 .UE oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen. .PP Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die .MT debian-l10n-german@lists.debian.org Mailingliste der Übersetzer .ME .