/tmp Verzeichnis... Sprünge durch neue Dateien

Ich könnte nicht sagen, das ich das zuvor schon mal so bemerkt hätte, momentan stört es mich aber sehr.
Wenn ich weiß, das ich Dateien nicht auf Dauer brauche, lade ich diese beim Download immer in's tmp Verzeichnis, da dies ja bei jedem reboot geleert wird.

Aktuell ist es aber extrem schwer eine Datei, die man dort gespeichert hat anzuklicken, weil die Dateinamen immer hin und her springen.
Das liegt wohl daran, das in extrem kurzen Abständen hier neue Verzeichnisse angelegt und gelöscht werden (siehe Gif:

)

Wie gesagt mache ich das schon sehr sehr lange so, aber erst seit ein paar Tagen (bzw. wenigen Wochen) fällt mir auf, das dieses Phänomen nun jedes mal auftritt.

Habt Ihr eine Ahnung, wie ich das beheben kann?

Post ins deutsche Unterforum verschoben
Moved post to german section

Hallo rethus,
zum Glück benutze ich ja kein systemd, aber ich vermute, Du musst herausfinden, welche Services die privateTmp-Option benutzen und diese Option abschalten.


dort "Solution 2"

viele Grüße gosia

1 Like

Du solltest auch überprüfen welches Programm abstürzt. Das zu beheben könnte helfen, den einer der erstellten private Ordner scheint für systemd-coredump zu sein.

Ich würde dir nicht empfehlen private tmp abzuschalten. Aber welche Sicherheitsmechanismen du verwenden willst ist natürlich deine Sache.

2 Likes

Scheint so, als ob es hier im Forum Leute gibt, die älter als ich sind, und sich nicht vom alt hergebrachten ... :wink:
ist das schon mal diskutiert worden? :wink:
Off Topic Off :smiley: :wink:

Hallo SGS,

na, das ist wahrscheinlich keine Kunst bei solch jungen Hüpfern. Ich kann mich noch an die Zeiten erinnern, als Computer mit Dampf betrieben wurden :wink:

Sowas nennt sich Altersweisheit :wink:

Aber ja doch. Gib mal in der Suche
openrc systemd
ein, da findet sich so allerhand. Ganz zu schweigen von der Diskussion überhaupt im Netz.

Hat ja dazu geführt, daß meine Systeme nur noch Artix und MX-Linux sind.

viele Grüße gosia

1 Like

warum legst du dir nicht einfach (noch) ein tmpfs verzeichnis für downloads an?

1 Like

Nehme an, das war ironisch.
Systemd vs. Sysvinit/OpenRC wurde (und wird noch immer) zu Tode diskutiert :wink:
Ich möchte jedenfalls nicht mehr zurück zu sysvinit.
Jedem das seine :wink:

Das scheint mir auch eine bessere Lösung zu sein.
Oder einfach einen Unterordner unter /tmp erstellen.

2 Likes

Also wenn ein coredump geschrieben wird, ist ein Programm abgestürzt? Dann würde es ja hier im Sekunden-Takt abstürzen.
Wie kann ich rausfinden welches das ist. Bemerkt, welches das sein könnte habe ich bis jetzt nicht.

Mit dem Befehl coredumpctl bekommst Du eine Liste der Coredumps.

Ok, danke. Aber wie analysiere ich die, damit ich weiß, wo jetzt genau das Problem liegt?

Die Liste zeigt an, welches Programm für den Coredump verantwortlich war, z.B.

TIME                            PID   UID   GID SIG COREFILE  EXE
Mon 2019-07-22 09:46:27 CEST   1177     0     0  31 none      /usr/bin/fc-cache-32

(siehe letzte Spalte)

Noch mehr Infos gibt's mit
coredumpctl info

Eventuell gibt es auch Einträge im normalen Journal, z.B. journalctl -p err

Ok, also journalctl zeigt mir dies:

und besagter coredumpbefehl dies:

Überhaupt mal das Kommando ausgeführt? Ein bisschen Eigeninitiative/Recherche kann man ja mal aufbringen, immerhin ist das deine Maschine mit dem Problem.
Wenn die ein Kommando neu/unbekannt ist

$ man coredumpctl

ist zumindest mal die erste Anlaufstelle und funktioniert sogar ohne Netz..

Schwer zu sagen was genau da los ist, aber das Problem taucht im Zusammenhang mit "thumbnail.so" auf, das anscheinend dann "kdeinit5" zum Absturz bringt.

Du könntest versuchen, testweise die Thumbnails zu deaktivieren, allerdings denke ich nicht, dass das viel bringt.

Ok, ich stöber dann diesbezüglich mal ein wenig im Netz. So hab ich wenigstens ein Anhaltspunkt, wonach ich suchen muss.
Danke erstmal für deine Hilfe torvic.

Ok hab noch mal genauer hingesehen:
libQt5Core 5.12.3 (deleted)
steht da.
Es scheint als ob thumbnail.so nach dieser älteren Version sucht.

Ist dein System auf dem letzten Stand?
Aktuell ist nämlich libQt5Core 5.13.

pacman -Qi qt5-base | grep Version
sollte 5.13 ausgeben.

ls -l /usr/lib/libQt5Core* sollte ebenfalls Module mit Versionsnummer 5.13 ausgeben.

partial upgrade oder vergessener Reboot nach Qt-Upgrade?

Gerade stand eh ein größeres KDE-Upgrade an. Habs durchgeführt und rebootet, scheint nun keine Probleme mehr mit dem Thumbs zu haben.
Thx.

Vielleicht mal die mirrors auffrischen, das letzte stable-Update ist mittlerweile schon 5 Tage da (https://forum.manjaro.org/t/stable-update-2019-07-17-kernels-kde-browsers-systemd-octopi-libreoffice/).

$ pacman-mirrors -f 5