SYSTEMD-COREDUMP(8) systemd-coredump SYSTEMD-COREDUMP(8) BEZEICHNUNG systemd-coredump, systemd-coredump.socket, systemd-coredump@.service - Erlangen, Speichern und Verarbeiten von Speicherauszugen UBERSICHT /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 Speicherauszuge zu verarbeiten. Es wird eine Zusammenfassung der Ereignisse nach systemd-journald.service(8) protokollieren, einschliesslich Informationen uber den Prozesskennzeichner, Eigentumer, das Signal, das den Prozess totete und (falls moglich) die Stack-Ablaufverfolgung (>>Stack-Trace<<). Es kann die Speicherauszuge auch fur eine spatere Verarbeitung speichern. Siehe den nachfolgenden Abschnitt >>Informationen uber abgesturzte 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 Speicherauszuge nur verarbeitet, wenn die zugehorigen Prozessressourcenbegrenzungen (RLIMIT_CORE) ausreichend sind. Speicherauszuge konnen in das Journal geschrieben oder als Datei gespeichert werden. In beiden Fallen konnen sie fur weitere Verarbeitungen, beispielsweise in gdb(1), abgefragt werden. Siehe coredumpctl(1), insbesondere die Verben list und debug. Standardmassig protokolliert systemd-coredump den Speicherauszug in das Journal, einschliesslich (falls moglich) einer Ablaufverfolgung (Backtrace) und speichert den Speicherauszug (ein Abbild der Speicherinhalte des Prozesses) selbst in einer externen Datei in /var/lib/systemd/coredump/. Diese Speicherauszuge werden nach ein paar Tagen standardmassig geloscht; siehe /usr/lib/tmpfiles.d/systemd.conf fur Details. Beachten Sie, dass die Entfernung von Speicherauszugsdateien aus dem Dateisystem und das Entfernen der Journal-Eintrage voneinander unabhangig sind, und die Speicherauszugsdatei ohne den Journal-Eintrag vorhanden sein kann und Journal-Eintrage auf bereits entfernte Speicherauszugsdateien verweisen konnen. Einige Metadaten werden an die Speicherauszugsdateien in Form von erweiterten Attributen angehangt, so dass die Speicherauszugsdateien fur einige Zwecke selbst ohne die vollstandigen Metadaten im Journal-Eintrag nutzlich sein konnen. Fur 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 tatsachlich ins Journal zu schreiben und die Speicherauszugsdateien zu verarbeiten und zu speichern. Wenn der Kernel systemd-coredump aufruft, um den Speicherauszug zu handhaben, lauft 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 Speicherauszugen vornehmen und der normalen Diensteverwaltung unterliegen. Es ist auch moglich, 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 samtliche zusatzliche Metadatenfelder, die der Aufrufende vernunftigerweise erwarten wurde, enthalten. systemd-coredump hangt zusatzliche Metadatenfelder auf die gleiche Art an, wie es das fur vom Kernel empfangene Speicherauszuge auch macht. In diesem Modus werden keine Speicherauszuge im Journal gespeichert. Speicherauszuge in Containern/Namensraumen Der Dienst systemd-coredump@.service wird automatisch versuchen, einen Stacktrace aus einem Prozess beim Absturz zu extrahieren. Fur diesen Stacktrace werden Symbole basierend auf Informationen, die in dem absturzenden ELF-Abbild eingebettet sind oder aus aquivalenten Fehlersuchinformationen, die auf dem Hauptbetriebssystem verfugbar sind, aufgelost. Fur Prozesse, die innerhalb von lokalen Containern oder anderen, Einhange-Namensraum-basierten Sandboxes absturzen, ist diese externe Fehlersuchinformation typischerweise nicht auf dem Hauptsystem verfugbar (einfach deshalb, weil Container typischerweise andere Software-Versionen als das Hauptsystem verwenden). systemd-coredump(8) stellt zwei Mechanismen bereit, um dies zu adressieren: 1. Fur Container mit vollstandigen Betriebssystemen, die innerhalb Systemd betreiben, wird empfohlen, CoredumpReceive= auf der Unit zu aktivieren (siehe systemd.resource-control(5)). Damit ist sichergestellt, dass versucht wird, Speicherauszuge eines Containers an den im Container betriebenen systemd-coredump@.service weiterzuleiten, d.h. der Container erhalt den Prozess und speichert seine eigenen Speicherauszuge. Beachten Sie, dass systemd-nspawn(8) standardmassig diesen Modus verwendet, falls es mit dem Schalter --boot aufgerufen wird. Diese Arbeitsweise wird im Allgemeinen aus Sicherheitsgrunden empfohlen: die sicherheitsrelevante Verarbeitung des Speicherauszugs erfolgt innerhalb der Begrenzungen des Containers selbst, durch den Code des Containers und hinterlegt durch den eigenen Speicher des Containers. 2. Fur restriktivere Container (die kein ordentliches Init-System als PID 1 verwenden) ist es alternativ moglich, die Verarbeitung des Speicherauszugs auf dem Hauptsystem zu aktivieren, mit Zugriff auf die Fehlersuchinformationsdaten aus dem Container selbst. Diese Arbeitsweise muss mittels EnterNamespace= in coredump.conf(5) aktiviert werden und ist standardmassig aus Sicherheitsgrunden ausgeschaltet. Falls sowohl CoredumpReceive= auf der Unit des Containers, zu dem der Speicherauszug gehort, als auch EnterNamespace= in der Konfigurationsdatei coredump.conf aktiviert sind, hat erstere Einstellung den Vorrang. KONFIGURATION Fur von systemd gestartete Programme konnen Prozessressourcenbegrenzungen mit der Direktive LimitCORE= eingerichtet werden, siehe systemd.exec(5). Um vom Kernel fur den Umgang mit Speicherauszugen eingesetzt zu werden, muss systemd-coredump im Parameter kernel.core_pattern von sysctl(8) konfiguriert sein. Die Syntax dieses Parameters wird in core(5) erklart. Systemd installiert die Datei /usr/lib/sysctl.d/50-coredump.conf, die kernel.core_pattern entsprechend konfiguriert. Diese Datei kann gemass normaler sysctl.d(5)-Regeln maskiert oder ausser Kraft gesetzt werden, um eine andere Einstellung zu verwenden. Falls die Sysctl-Konfiguration verandert 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 Anderungen in diesen Dateien wirksam, wenn das nachste Mal ein Speicherauszug empfangen wird. Die von Speicherauszugen verwandten Ressourcen werden auf zwei Arten begrenzt. Parameter wie die maximale Grosse empfangener Speicherauszuge und Dateien konnen in den oben erwahnten Dateien /etc/systemd/coredump.conf und Schnippseln geandert werden. Zusatzlich wird die Speicherdauer von Speicherauszugen durch systemd-tmpfiles beschrankt, entsprechende Einstellungen sind standardmassig in /usr/lib/tmpfiles.d/systemd.conf. Standardmassig werden die Speicherauszuge nach ein paar Tagen geloscht; weitere Details finden Sie in obiger Datei. Deaktivierung der Verarbeitung von Speicherauszugen Um die moglicherweise ressourcenintensive Verarbeitung durch systemd-coredump zu deaktivieren, setzen Sie Storage=none ProcessSizeMax=0 in coredump.conf(5). INFORMATIONEN UBER ABGESTURZTE PROZESSE coredumpctl(1) kann zur Abfrage gespeicherter Speicherauszuge, unabhangig 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 konnen auch wie gewohnlich 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 Eigentumers des abgesturzten Prozesses. Falls der abgesturzte Prozess Teil eines Containers war (oder im allgemeinen in einem Prozess- oder Benutzernamensraum war), sind dies die von aussen gesehenen Werte, im Namensraum, in dem systemd-coredump lauft. Hinzugefugt in Version 248. COREDUMP_BY_PIDFD= Falls der abgesturzte Prozess mittels einer vom Kernel bereitgestellten PIDFD analysiert wurde (benotigt Kernel v6.16), dann wird dieses Feld vorhanden und auf >>1<< gesetzt sein. Falls dieses Feld nicht gesetzt ist, dann wurde dieser Prozess mittels einer PID analysiert, die bekanntermassen Wettlaufen um Ressourcen unterliegt. Hinzugefugt in Version 258. COREDUMP_TIMESTAMP= Die Uhrzeit vom Absturz, wie vom Kernel gemeldet (in s seit der Epoch). Hinzugefugt in Version 248. COREDUMP_RLIMIT= Die weiche Ressourcenbegrenzung fur Speicherauszugsdateien, siehe getrlimit(2). Hinzugefugt in Version 248. COREDUMP_UNIT=, COREDUMP_SLICE= Die Namen der System-Unit und der Scheibe. Wenn der abgesturzte Prozess sich in einem Container befand, sind dies die Unit-Namen ausserhalb, im Haupt-Systemverwalter. Hinzugefugt in Version 248. COREDUMP_CGROUP= Die primare Cgrup der Unit des abgesturzten Prozesses. Wenn der abgesturzte Prozess sich in einem Container befand, ist dies der vollstandige Pfad, wie er ausserhalb des Containers gesehen wird. Hinzugefugt 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 abgesturzte Prozess sich in einem Container befand, ist dies der vollstandige Pfad, wie er ausserhalb des Containers gesehen wird. Hinzugefugt 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 abgesturzten Prozesses gehort, die Benutzerverwalter-Unit und den Sitzungskennzeichner. Alle drei Felder sind nur fur Benutzerprozesse vorhanden. Wenn sich der abgesturzte Prozess in einem Container befand, sind dies die Werte ausserhalb, im Hauptsystem. Hinzugefugt 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.) Hinzugefugt in Version 248. COREDUMP_CWD=, COREDUMP_ROOT= Das aktuelle Arbeitsverzeichnis und Wurzelverzeichnis des abgesturzten Prozesses. Wenn sich der abgesturzte Prozess in einem Container befand, sind diese Pfade relativ zur Wurzel des Einhangenamensraums des Containers. Hinzugefugt in Version 248. COREDUMP_DUMPABLE= Das vom Kernel berichtete Feld PR_GET_DUMPABLE, siehe prctl(2). Hinzugefugt in Version 258. COREDUMP_OPEN_FDS= Informationen uber offene Dateideskriptoren, in den folgenden Formaten: fd:/Pfad/zur/Datei pos: flags: fd:/Pfad/zur/Datei pos: flags: Die erste Zeile enthalt die Dateideskriptorennummer fd und den Pfad, wahrend nachfolgende Zeilen die Inhalte von /proc/PID/fdinfo/fd anzeigen. Hinzugefugt in Version 248. COREDUMP_EXE= Das Ziel des Symlinks /proc/PID/exe. Wenn sich der abgesturzte Prozess in einem Container befindet, ist der Pfad relativ zu der Wurzel des Einhangenamensraums des Containers. Hinzugefugt in Version 248. COREDUMP_CMDLINE=, COREDUMP_COMM=, COREDUMP_ENVIRON=, COREDUMP_PROC_AUXV=, COREDUMP_PROC_LIMITS=, COREDUMP_PROC_MAPS=, COREDUMP_PROC_MOUNTINFO=, COREDUMP_PROC_STATUS= Felder, die die prozessbezogenen Eintrage im Dateisystem /proc zuordnen: /proc/PID/cmdline (die Befehlszeile des abgesturzten Prozesses), /proc/PID/comm (der dem Prozess zugeordnete Befehlsname), /proc/PID/environ (der Umgebungsblock des abgesturzten Prozesses), /proc/PID/auxv (der Hilfsvektor des abgesturzten Prozesses, siehe getauxval(3)), /proc/PID/limits (die weichen und die harten Ressourcenbegrenzungen), /proc/PID/maps (Speicherregionen, die fur den Prozess sichtbar sind und die zugehorigen Zugriffsberechtigungen), /proc/PID/mountinfo (Einhangepunkte im Einhangenamensraum des Prozesses), /proc/PID/status (verschiedene Metadaten des Prozesses). Siehe proc(5) fur weitere Informationen. Hinzugefugt in Version 248. COREDUMP_HOSTNAME= Der System-Rechnername. Wenn sich der abgesturzte Prozess in einem Container befand, ist dies der Rechnername des Containers. Hinzugefugt in Version 248. COREDUMP_CONTAINER_CMDLINE= Fur Prozesse, die in einem Container ausgefuhrt werden, die Befehlszeile des Prozesses, der den Container gestartet hat (der erste ubergeordnete Prozess mit einem anderen Einhangenamensraum). Hinzugefugt in Version 248. COREDUMP= Wenn der Speicherauszug im Journal gespeichert wurde, das Speicherauszugsabbild selbst. Hinzugefugt in Version 248. COREDUMP_FILENAME= Wenn der Speicherauszug extern gespeichert wurde, der Pfad zu der Speicherauszugsdatei. Hinzugefugt in Version 248. COREDUMP_TRUNCATED= Auf >>1<< gesetzt, wenn der gespeicherte Speicherauszug abgeschnitten wurde. (Eine unvollstandige Speicherauszugsdatei kann von einigen Werkzeugen noch verarbeitet werden, obwohl logischerweise nicht die vollstandigen Informationen vorhanden sind.) Hinzugefugt in Version 248. COREDUMP_PACKAGE_NAME=, COREDUMP_PACKAGE_VERSION=, COREDUMP_PACKAGE_JSON= Falls das Programm .package-Metadaten-ELF-Bemerkungen enthalt, werden diese ausgewertet und angehangt. Das Paket und die Version des [u00BB]Haupt[u00AB]-ELF-Moduls (d.h. des Programms) werden einzeln angehangt. Der JSON-formatierte Inhalt aller Module wird als einzelnes JSON-Objekt angehangt, jedes mit dem Modulnamen als Schlussel. Fur weitere Informationen uber dieses Metadatenformat und den Inhalt, siehe die Paket-Metadaten fur ausfuhrbare Dateien[5]. Hinzugefugt in Version 249. MESSAGE= Die durch systemd-coredump erstellte Nachricht, die die Ablaufverfolgung enthalt, falls sie erfolgreich erstellt wurde. Wird systemd-coredump mit --backtrace aufgerufen, dann wird das Feld vom Aufrufenden bereitgestellt. Hinzugefugt in Version 248. Im Journal-Eintrag existieren eine Reihe von weiteren Feldern, die aber dem Protokollierungsprozess betreffen, d.h. systemd-coredump und nicht den abgesturzten Prozess. Siehe systemd.journal-fields(7). Die folgenden Felder werden mit der in COREDUMP_FILENAME= aufgefuhrten 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=. Hinzugefugt in Version 248. Diese konnen sich mittels getfattr(1) angeschaut werden. Fur 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 Prafix; kill(2) verwendet den Prafix; alle Systemd-Werkzeuge akzeptieren Signalnamen sowohl ohne als auch mit dem Prafix. 5. Paket-Metadaten fur ausfuhrbare Dateien https://systemd.io/PACKAGE_METADATA_FOR_EXECUTABLE_FILES/ UBERSETZUNG Die deutsche Ubersetzung dieser Handbuchseite wurde von Helge Kreutzmann erstellt. Diese Ubersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezuglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG ubernommen. Wenn Sie Fehler in der Ubersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Ubersetzer . systemd 260.2 SYSTEMD-COREDUMP(8)