Manjaro-Linux-Forum

Im Verzeichnis:
/var/lib/systemd/coredump
liegen durch meine Probleme mit dem KDE-Musikplayer ELISA viele Dateien wie:
core.elisa.1000.227d21358b41445893f8fd922c15ab45.1987.1758632576000000.zst

Dieses Problem ist durch verschieben von Musikdateien entstanden.
Elisa hatte in der Playliste Titel die nicht mehr vorhanden waren, wollte sie einlesen, konnte sie nicht öffen und stürzte jedesmal kurz nach dem Start ab.

Gibt es für diese Fehlerbericht-Dateien ein Archivierungszeitraum bzw. werden diese dann automatisch gelöscht?

Unter /etc/systemd/coredump.conf konnte ich folgende Konfiguration finden:

[Coredump]
#Storage=external
#Compress=yes
# On 32-bit, the default is 1G instead of 32G.
#ProcessSizeMax=32G

Bedeutet diese Konfiguration, alles über 32GB wird gelöscht darunter liegend archiviert oder ist der Archivierungszeitraum an anderer Stelle zu finden?

Lassen sich die core.zst-DATEIEN bedenkenlos löschen,
z. B. natürlich besser über: und dann: oder könnten Probleme daraus entstehen.

Ist es zu empfehlen den Eintrag in der "coredump.conf"
>> auf:
[Coredump]
Storage=none
zu setzen, da ich zur Zeit noch kein Wissen über dbg habe, bringen sie mir kein echten Nutzen?

Hallo Lilli-Manjaro,
wenn Du core dumps nicht analysieren kannst oder willst, kannst (besser "solltest") Du sie bedenkenlos löschen. Je nach deinen Einstellungen geschieht dies nach bestimmten Zeiten bzw. Grössen eigentlich automatisch. Am besten ist es in diesem Fall core dumps überhaupt abzuschalten.
Am besten sieh dir diesen Artikel an:
https://wiki.archlinux.org/title/Core_dump


viele Grüsse gosia

Die sind bei dir lokal gespeichert, weil in der conf Datei die Speicherung nach Extern auskommentiert ist, d.h. das wurde gar nicht konfiguriert.
Hier könntest du die Dumps nach "Externe Platte/USB Sticke/whataver" umleiten, aber wie gesagt, die conf macht an der Stelle gar nichts.

Mit "coredumpctl list" kannst du dir alle Dumps anzeigen lassen.
gosia hat ja schon den Link gepostet, dort steht dann unten wie du die "analysieren" kannst.

Oder, einfach wegschmeissen den Mist. Das ist eigentlich nur für die Entwickler interessant wenn ihr Programm abstürzt (oder andere Fehler verursacht).

Danke euch für die Antworten.

Doch bevor ich Änderungen an der Konfiguration vornehme werde ich mich wohl besser noch etwas mehr belesen, damit nichts daneben geht und brauch dazu etwas mehr Zeit bzw. Ruhe die ich im Moment nicht habe, da es noch andere Baustellen auf mein System gibt die zu erledigen sind. Denn mein Ziel auf Windows ganz zu verzichten scheint für mich nicht so recht umsetzbar zu sein. Suche immer noch eine optimale Lösung zu Mp3Tag-Editor und foobar2000, werde es wahrscheinlich in einer VM im Heimnetz laufen lassen, um nicht ganz auf bestimmte Funktionen der Programme verzichten zu müssen. Wirkliche Alternativen dazu konnte ich unter Linux leider bisher nicht finden. Wenn dies alles erledigt ist wende ich mich wieder der Konfiguration von "core dumb" zu. Wobei das Debuggen schon interessant sein könnte, aber dies steht wohl eher noch sehr weit in der Zukunft, falls überhaupt.

Bedeutet das # in: /etc/systemd/coredump.conf am Anfang der Zeilen:
Kommentar bzw. nicht konfiguriert:
[Coredump]
#Storage=external
#Compress=yes
# On 32-bit, the default is 1G instead of 32G.
#ProcessSizeMax=32G
#ExternalSizeMax=32G
#JournalSizeMax=767M
#MaxUse=
#KeepFree=
#EnterNamespace=no

... und müsste der Eintrag dann so aussehen:
[Coredump]
Storage=none
#Compress=yes
# On 32-bit, the default is 1G instead of 32G.
ProcessSizeMax=0G
#ExternalSizeMax=32G
#JournalSizeMax=767M
#MaxUse=
#KeepFree=
#EnterNamespace=no

Wenn ich es richtig verstanden habe gibt es auch noch eins, zwei andere Dateien die abgeändert werden müssen.

LG Lilli

Hallo Lilli-Manjaro,
ich glaube, Du überschätzt das auftreten von core dumps Kommen normalerweise seltener vor (jedenfalls wenn Du dich an die offiziellen Pakete hältst) und wenn, kann man sie getrost löschen. Aber zum eigentlichen, ja, das setzen von Storage auf Null verhindert, das die core dumps mitgeschleppt werden. Die Option "none" bedeutet, dass core dumps nicht dauerhaft gespeichert werden.

Was die Rauten betrifft, die bedeuten, dass alles dahinter als Kommentar aufgefasst und somit nicht beachtet, bzw. dafür Default-Werte benutzt werden. Der Defaultwert für "storage" ist übrigens „external“, das bedeutet, dass core dumps in /var/lib/systemd/coredump/ gespeichert werden.
"ProcessSizeMax" gibt die maximale Größe der core dumps an (Default 1 GB auf 32-Bit-Systemen und 32 GB auf 64-Bit-Systemen). Das auf Null zu setzen ist also eine gute Idee (der Suffixe G ist in dem Fall überflüssig, dürfte aber auch nicht schaden).
Diese Kombination verhindert also die ganze core dump Verarbeitung und ist die perfekte Lösung (wie in https://wiki.archlinux.org/title/Core_d ... ng_systemd beschrieben)

Lilli-Manjaro hat geschrieben: ↑Donnerstag 25. September 2025, 10:23 gibt es auch noch eins, zwei andere Dateien die abgeändert werden müssen

nicht dass ich wüsste, lasse mich aber gern überzeugen

viele Grüsse gosia

PS. für die nächsten Threads zur mp3-Tag-Bearbeitung und zum Audio player solltest Du unbedingt erklären, was dir an beiden Programme besonders wichtig ist. Beides gibt es auch unter Linux wie Sand am Meer, nur eben in verschiedenen Geschmacksrichtungen, so dass man schon wissen muss, worauf Du dabei Wert legst. Ich z.B. bin mit Strawberry https://www.strawberrymusicplayer.org/
völlig zufrieden, aber vielleicht fehlen ihm Funktionen von foobar2000, die Du nicht missen möchtest.

Lilli-Manjaro hat geschrieben: ↑Donnerstag 25. September 2025, 10:23 ... Denn mein Ziel auf Windows ganz zu verzichten scheint für mich nicht so recht umsetzbar zu sein. Suche immer noch eine optimale Lösung zu Mp3Tag-Editor und foobar2000, werde es wahrscheinlich in einer VM im Heimnetz laufen lassen, um nicht ganz auf bestimmte Funktionen der Programme verzichten zu müssen. Wirkliche Alternativen dazu konnte ich unter Linux leider bisher nicht finden.

Ich habe auch lange eine Alternative zu foobar2000 gesucht. Anfangs hatte ich "deadbeef" genutzt, aber es ist etwas gewöhnungsbedürftig das UI einzurichten bis es passt, zudem verhält es sich dennoch anders als "foobar2000".
Dann bin ich auf "Quod Libet" gestoßen. Als Abhängigkeit wird automatisch der Tagger "Ex Falso" mitinstalliert.
Vielleicht gefällt die das Programm ja. Der Tagger interessierte mich aber eher weniger - ist aber quasi im Player integriert.

edit:

Hier mal ein Link: Quod Libet

edit2:

Was mir unter anderem wichtig war, ist dass man eine Verzeichnisansicht wie bei foobar2000 einstellen kann.

Lilli-Manjaro hat geschrieben: ↑Donnerstag 25. September 2025, 10:23 …Suche immer noch eine optimale Lösung zu Mp3Tag-Editor und foobar2000…

Fooyin ist als Foobar2000 Ersatz nicht schlecht. Nutze ich jetzt auch. Ist zwar noch in der Entwicklung, funktioniert aber sehr gut.
Habe es aus dem Chaotic-AUR installiert es gibt Fooyin aber auch im AUR oder auch als Flatpak.

https://fooyin.org/
https://github.com/fooyin/fooyin

Lilli-Manjaro hat geschrieben: ↑Donnerstag 25. September 2025, 10:23 Suche immer noch eine optimale Lösung zu Mp3Tag-Editor und foobar2000, werde es wahrscheinlich in einer VM im Heimnetz laufen lassen, um nicht ganz auf bestimmte Funktionen der Programme verzichten zu müssen.

Mit einer Alternative zu foobar2000 kann ich nicht helfen, aber Mp3Tag-Editor gibt es im AUR, das ist der gleiche wie von Windows, läuft anscheinend unter wine: Aber hast du schon mal von puddletag gehört? Seit ich den getestet habe, nutze ich mp3tag nicht mehr.

PS
Tools zur Audio Bearbeitung und zum taggen gibt es unter Linux jede Menge. Meiner Meinung nach braucht man da nichts mehr von Windows.

Wollte auch gerade Puddletag vorschlagen. Nutze auch nur mehr diesen.

gosia hat geschrieben: ↑Donnerstag 25. September 2025, 11:44 Hallo Lilli-Manjaro, ...

Lilli-Manjaro hat geschrieben: ↑Donnerstag 25. September 2025, 10:23 gibt es auch noch eins, zwei andere Dateien die abgeändert werden müssen

nicht dass ich wüsste, lasse mich aber gern überzeugen

Keine Ahnung ob das korrekt ist::

Dies ist die empfohlene Methode für eine System-weite Deaktivierung.
Dauerhafte Deaktivierung über /etc/security/limits.conf

1. Öffnen Sie die Konfigurationsdatei: mit einem Texteditor und Root-Rechten, zum
Beispiel:
>> Code:
sudo nano /etc/security/limits.conf

2. Fügen Sie die folgenden Zeilen hinzu, um die maximale Größe von Core-Dateien für alle Benutzer auf 0 zu setzen:
>> Code:
* hard core 0
* soft core 0

Hallo Lilli-Manjaro,

Lilli-Manjaro hat geschrieben: ↑Freitag 26. September 2025, 13:20 Dies ist die empfohlene Methode für eine System-weite Deaktivierung.
Dauerhafte Deaktivierung über /etc/security/limits.conf

Interessant. Du meinst das hier (bitte künftig die Quelle angeben):
https://wiki.archlinux.org/title/Limits.conf
Tja, müsste ich mal austesten. Aber mich machen manche Anmerkungen dort stutzig:
1. "allows setting resource limits for users logged in via PAM" -> ich melde mich jedenfalls nicht per PAM an, brauche ich das da? Ich denke nein
2. "This should cover setting limits in systemd configs as well" und "The file does not affect system services. For systemd services the files ..." -> tja, was denn nun? Sollte dies nun auch die Grenzwerte in systemd abdecken (erster Satz), oder brauche ich für systemd auch noch die im zweiten Satz erwähnten conf? Widerspricht der erste Satz nicht etwas dem zweiten?
Fragen über Fragen, die ich nicht beantworten kann. Aber da ich mit meiner erwähnten Methode in Post #5 bisher gut gefahren bin (seit Jahrzehnten keinen core dump mehr gesehen) nehme ich mal an, das reicht. Aber da core dumps 1. nur Platz wegnehmen und 2. für kundige Neugierige Geheimnisse verraten könnten (wer allerdings Zugriff auf deinen Rechner hat, um die core dumps zu lesen, der kann viel leichter noch anderen Unfug treiben) halte ich die Befürchtungen für übertrieben. Ich will dich aber nicht davon abhalten, auch diesen zusätzlichen Weg zu beschreiten, schadet nicht, ist IMHO nur überflüssig.

viele Grüsse gosia