Beiträge von Oceanwaves

    Evtl. wurden die Verzeichnisse (noch) nicht gelöscht, weil Dateien unterhalb der Verzeichnisse gelöscht wurden. Bei der Dolphin-Datei kann ich es nicht mehr sagen, weil ich sie mir heute mal angeschaut habe und dadurch natürlich die Access Time auf heute Vormittag gesetzt wurde. Ich beobachte es weiter, aber immerhin sind die meisten alten Dateien jetzt weg. Ich denke, das Problem ist behoben...

    Irgendetwas ist passiert. Ich hatte gestern den Wert in /etc/tmpfiles.d/fs-tmp.conf von 10d auf 3d reduziert. Und auch ein Update auf

    openSUSE-release-20201125 installiert. Heute morgen waren dann 20 GB Daten in /tmp weg... Seltsamerweise sind noch 3 Verzeichnisse aus Oktober sowie eine von Dolphin am 11.11. erzeugte Datei dort, aber es wurde definitiv einiges gelöscht.


    Und journalctl meldet jetzt auch, dass die tmp-Verzeichnisse aufgeräumt wurden. Nur /usr/lib/tmpfiles.d/net-snmp.conf muss ich wohl noch mal kopieren und fixen:

    Code
     # journalctl  -u systemd-tmpfiles-clean
    -- Logs begin at Sun 2020-11-29 09:20:15 CET, end at Sun 2020-11-29 10:10:52 CET. --
    Nov 29 09:35:29 frodo systemd[1]: Starting Cleanup of Temporary Directories...
    Nov 29 09:35:29 frodo systemd-tmpfiles[6788]: /usr/lib/tmpfiles.d/net-snmp.conf:1: Line references path below legacy directory /var/run/, updat>
    Nov 29 09:35:29 frodo systemd[1]: systemd-tmpfiles-clean.service: Succeeded.
    Nov 29 09:35:29 frodo systemd[1]: Finished Cleanup of Temporary Directories.

    Du hast 10 Tage eingestellt = 10d


    Schau mal nach, nicht das es jetzt eine neue Datei in /etc/tmpfiles.d/ gibt.

    Nein, warum sollte da eine neue Datei sein? Ich habe 2 Dateien aus /usr/lib/tmpfiles.d dorthin kopiert und sie modifiziert. Das Betriebssystem sollte keine Dateien nach /etc/tmpfiles.d kopieren.

    Ich habe "10d" so verstanden, dass Dateien, die älter als 10 Tage sind, aus /tmp gelöscht werden. Das passiert aber nicht, die älteste Datei in /tmp ist weiterhin vom 18.10.20. Danach kommen gut 180 Dateien (*.tmp) vom 20.10. Die neuesten sind natürlich von heute.


    Die Diskussion im englischen SuSE-Forum hatte ich gestern schon gelesen, hat mir aber auch nicht geholfen.


    Ich gehe momentan davon aus, dass ich bis Mitte Oktober eine tmp.conf in /usr/lib/tmpfiles.d hatte, denn die manpage sagt: "

    Files in /etc/tmpfiles.d override files with the same name in /usr/lib/tmpfiles.d and /run/tmpfiles.d." Man beachte "same name". Da ich in /usr/lib/tmpfiles.d keine tmp.conf habe, dafür aber fs-tmp.conf und fs-var-tmp.conf, die jeweils Cleanup-Einträge für /tmp bzw. /var/tmp enthalten, ist auch meine Fehlermeldung beim Aufruf des Dienstes mit /etc/tmpfiles.d/tmp.conf erklärlich:


    Code
    -- Logs begin at Fri 2020-11-27 06:16:50 CET, end at Fri 2020-11-27 14:49:36 CET. --
    Nov 27 06:32:05 frodo systemd[1]: Starting Cleanup of Temporary Directories...
    Nov 27 06:32:05 frodo systemd-tmpfiles[6779]: /usr/lib/tmpfiles.d/net-snmp.conf:1: Line references path below legacy directory /var/run/, updat>
    Nov 27 06:32:05 frodo systemd-tmpfiles[6779]: /etc/tmpfiles.d/tmp.conf:13: Duplicate line for path "/tmp", ignoring.
    Nov 27 06:32:05 frodo systemd-tmpfiles[6779]: /etc/tmpfiles.d/tmp.conf:14: Duplicate line for path "/var/tmp", ignoring.
    Nov 27 06:32:05 frodo systemd[1]: systemd-tmpfiles-clean.service: Succeeded.

    "Duplicate line" wurde wohl gemeldet, weil es Anweisungen für /tmp in /usr/lib/tmpfiles.d/fs-tmp.conf und in /etc/tmpfiles.d/tmp.conf gab. Nachdem ich die tmp.conf entfernt hatte, gab es keine doppelten Einträge für /tmp und /var/tmp.

    Die Datei /etc/tmpfiles.d/fs-tmp.conf übersteuert jetzt Einträge in /usr/lib/tmpfiles.d/fs-tmp.conf.


    Was ich erreichen möchte, ist, dass Dateien in /tmp, die älter als "x" tage sind, gelöscht werden. Ich möchte nicht, dass /tmp bei jedem Neustart komplett gelöscht wird. Dann könnte ich /tmp auch als tmpfs mounten.

    Die hatte ich ja im Prinzip schon mal hier gepostet. Ich habe die zwei Dateien fs-tmp.conf und fs-var-tmp.conf (in /usr/lib/tmpfiles.d, aus dem Paket filesystem-15.5-34.1.x86_64) nach /etc/tmpfiles.d kopiert und dann in fs-tmp.conf das "q" durch ein "d" ersetzt und in fs-var-tmp.conf den Age-Parameter "-" durch "10d" ersetzt.

    Code
    ~ # ll /etc/tmpfiles.d
    total 8
    -rw-r--r-- 1 root root 26 Nov 27 18:23 fs-tmp.conf
    -rw-r--r-- 1 root root 30 Nov 27 18:24 fs-var-tmp.conf
    Code
    ~ # cat /etc/tmpfiles.d/*.conf
    d /tmp 1777 root root 10d
    d /var/tmp 1777 root root 10d
    Code
    ~ # systemd-tmpfiles --clean
    /usr/lib/tmpfiles.d/net-snmp.conf:1: Line references path below legacy directory /var/run/, updating /var/run/net-snmp → /run/net-snmp; please update the tmpfiles.d/ drop-in file accordingly.

    Grundsätzlich ist die Anleitung für Leap und Tumbleweed wohl identisch: die Konfig-Dateien liegen in /usr/lib/tmpfiles.d. Wenn man sie anpassen möchte, sollte man sie nach /etc/tmpfiles.d kopieren und dort editieren, da die Dateien in /usr/lib/tmpfiles.d bei einem Update sonst überschrieben werden. Für /tmp und /var/tmp ist die Datei tmp.conf zu kopieren. Für Tumbleweed wurde das Paket filesystem aber wohl mal dahingehend geändert, dass tmp.conf in mehrere Dateien aufgesplittet wurde, u.a. fs-tmp.conf (für /tmp) und fs-var-tmp.conf (für /var/tmp). Bislang habe ich noch keine Release Notes für das Paket filesystem gefunden, weiß daher nicht, wann dies passiert ist.


    Fakt ist, dass bei mir seit Oktober weder /tmp noch /var/tmp bereinigt werden, momentan funktioniert das nur noch manuell :(.

    Nein.

    Wenn in /etc/tmpfiles.d/ keine config vorliegt und eine config in /usr/lib/tmpfiles.d/ vorliegt, wird die aus /usr/lib/tmpfiles.d/fs-tmp.conf natürlich benutzt.


    Wenn in beiden Verzeichnissen eine config vorliegt, wird immer die aus /etc/tmpfiles.d/ genommen.

    Das Löschen der /etc/tmpfiles.d/tmp.conf hat immerhin dazu geführt, dass journalctl keine Fehler mehr meldet, also keine "duplicate line". Allerdings steht im Log jetzt auch nicht mehr "Starting Cleanup of Temporary Directories...":


    Code
     # journalctl  -u systemd-tmpfiles-clean
    -- Logs begin at Fri 2020-11-27 18:24:41 CET, end at Fri 2020-11-27 18:35:06 CET. --
    -- No entries --

    Startet systemd den Prozess nur ein Mal am Tag?


    Ich habe fs-tmp.conf und fs-var-tmp.conf nach /etc/tmpfiles.d/tmp.conf kopiert und beide etwas modifiziert:

    Code
    /etc/tmpfiles.d # diff ~-/fs-tmp.conf fs-tmp.conf 
    1c1
    < q /tmp 1777 root root 10d
    ---
    > d /tmp 1777 root root 10d
    /etc/tmpfiles.d # diff ~-/fs-var-tmp.conf fs-var-tmp.conf 
    1c1
    < d /var/tmp 1777 root root -
    ---
    > d /var/tmp 1777 root root 10d

    Hat aber auch nichts gebracht, es wurde bei einem Reboot nichts gelöscht.

    Noch mal etwas recherchiert: /etc/tmpfiles.d/tmp.conf soll ja eigentlich eine Kopie von /usr/lib/tmpfiles.d/tmp.conf sein, die man nach eigenen Wünschen anpassen kann. Aber in /usr/lib/tmpfiles.d gibt es hier keine tmp.conf (mehr). Stattdessen habe ich aber die folgenden Dateien gefunden:

    Code
    -rw-r--r-- 1 root root  26 Oct 23 12:23 fs-tmp.conf
    -rw-r--r-- 1 root root  28 Oct 23 12:23 fs-var-tmp.conf
    -rw-r--r-- 1 root root 483 Oct 23 12:23 fs-var.conf

    Die gehören zum Paket filesystem und wurden im Oktober installiert. Und fs-tmp.conf enthält einen Eintrag für /tmp:


    Code
     # cat fs-tmp.conf
    q /tmp 1777 root root 10d

    Lt. man-page wäre die Syntax auch nicht korrekt ;), aber ich habe jetzt mal /etc/tmpfiles.d/tmp.conf weggeschoben und schaue mal, was passiert.

    Vielleicht stört sich systemd ja daran, dass /tmp und /var/tmp sowohl in /etc/tmpfiles.d/tmp.conf als auch in /usr/lib/tmpfiles.d/fs-tmp.conf bzw. /usr/lib/tmpfiles.d/fs-var-tmp.conf definiert sind.

    Ja, das war auch mein erster Gedanke. Aber wie gesagt: /etc/tmpfiles.d/tmp.conf liegt dort unverändert seit dem 14.07.2019, aber seit Mitte Oktober bleiben die Dateien in /tmp liegen, die älteste Datei ist vom 18.10.20. Und der Dienst systemd-tmpfiles-clean meckert ja wegen doppelter Einträge, was mich etwas verwirrt, weil ich die dort nicht finde.