Datei verschwindet über Nacht, wie überwachen ?

  • Ich habe ein merkwürdiges Problem mit einem Pi Zero W:

    Beim booten werden mit @reboot via crontab -e mehrere Dateien in /dev/shm erstellt.

    Das funktioniert auch wunderbar, doch eine Datei verschwindet immer wieder.

    Der Zero läuft mit OverlayFS, wenn ich ihn neu starte, ist die Datei wieder da, irgendwann verschwindet sie wieder auf mysteriöse und geheimnisvolle Weise.

    Angelegt werden sie sudo crontab -e und sehen so aus:

    Code
    @reboot touch /dev/shm/datei1.txt && chown pi:pi /dev/shm/datei1.txt
    @reboot touch /dev/shm/datei2.txt && chown pi:pi /dev/shm/datei2.txt
    @reboot touch /dev/shm/datei3.txt && chown pi:pi /dev/shm/datei3.txt
    ...
    ###############

    Das kuriose ist, dass immer nur diese eine Datei verschwindet.

    Ich habe gerade das Tools inotify gefunden und installiert.

    Dort sehe ich mit inotifywait -m --timefmt '%F %T' --format '%T %w %e' /dev/shm/ diese Ausgabe, wenn ich z.B. mit dem Browser darauf zugreife:

    Code
    Setting up watches.
    Watches established.
    2021-11-09 08:32:40 /dev/shm/datei1.txt OPEN 
    2021-11-09 08:32:40 /dev/shm/datei1.txt ACCESS 
    2021-11-09 08:32:40 /dev/shm/datei1.txt CLOSE_NOWRITE,CLOSE 

    Leider sehe ich nicht, wer bzw. welches Programm zugreift, wie z.B. mit Firefox.

    Gibt es da vielleicht einen Kniff oder ein anderes Programm dafür ? :helpnew:

  • Moin fred0815,

    ist die datei1.txt wirklich gelöscht. Weil, laut manpage, inotifywait auch delete ausgegeben wird.

    Heißen die Dateien wirklich so, oder sind es nur Beispiele?

    Du könntest es mit lsof probieren. Der hat auch einen repeat-Modus.

    73 de Bernd

    Ich habe KEINE Ahnung und davon GANZ VIEL!!
    Bei einer Lösung freue ich mich über ein ":thumbup:"
    Vielleicht trifft man sich in der RPi-Plauderecke.
    Linux ist zum Lernen da, je mehr man lernt um so besser versteht man es.

  • Zur Installation von inotify musste ich das Overlay entfernen und neu starten, dabei wurde die Datei neu erstellt. Dann habe ich die Datei im Browser aufgerufen und die obige Ausgabe erhalten. Jetzt warte ich darauf, dass sie wieder verschwindet.

    lsof probiere ich mal, wenn ich Zuhause bin.

    Dateinamen sind Beispiele, aber reine .txt.

  • Beim booten werden mit @reboot via crontab -e mehrere Dateien in /dev/shm erstellt.

    Das funktioniert auch wunderbar, doch eine Datei verschwindet immer wieder.

    Der Zero läuft mit OverlayFS, wenn ich ihn neu starte, ist die Datei wieder da, irgendwann verschwindet sie wieder auf mysteriöse und geheimnisvolle Weise.

    Angelegt werden sie sudo crontab -e und sehen so aus:

    Code
    @reboot touch /dev/shm/datei1.txt && chown pi:pi /dev/shm/datei1.txt
    @reboot touch /dev/shm/datei2.txt && chown pi:pi /dev/shm/datei2.txt
    @reboot touch /dev/shm/datei3.txt && chown pi:pi /dev/shm/datei3.txt
    ...
    ###############

    Das kuriose ist, dass immer nur diese eine Datei verschwindet.

    /dev/shm ist ja ein tmpfs. Wie sind die Ausgaben von:

    Code
    stat /dev/shm/datei1.txt
    stat /dev/shm/datei2.txt

    sofort nach dem booten und wie ist die Ausgabe von:

    Code
    stat /dev/shm/datei2.txt

    , wenn die Datei "datei1.txt" verschwunden ist?

    Versuch mal sofort nach dem booten mit:

    Code
    sudo chattr +i /dev/shm/datei1.txt

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden
    "Das dauert plötzlich ½ Sekunde länger. Das muss ich mir anschauen!" - Andres Freund

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.5 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p6 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, Mumble-Server, botamusique, ample

  • Das war nach dem Neustart heute morgen um 8:16 Uhr, nachdem ich das Overlay ausgemacht hatte und inotify installiert hatte::

    Code
    stat /dev/shm/datei1.txt 
      Datei: /dev/shm/datei1.txt
      Größe: 2             Blöcke: 8          EA Block: 4096   reguläre Datei
    Gerät: 19h/25d    Inode: 3           Verknüpfungen: 1
    Zugriff: (0644/-rw-r--r--)  Uid: ( 1000/      pi)   Gid: ( 1000/      pi)
    Zugriff    : 2021-11-09 16:09:23.854745291 +0100
    Modifiziert: 2021-11-09 08:16:31.230000000 +0100
    Geändert   : 2021-11-09 08:16:31.230000000 +0100
     Geburt    : -

    Andere Datei, die immer neu überschrieben wird:

    Code
    stat /dev/shm/datei2.txt 
      Datei: /dev/shm/datei2.txt
      Größe: 4             Blöcke: 8          EA Block: 4096   reguläre Datei
    Gerät: 19h/25d    Inode: 5           Verknüpfungen: 1
    Zugriff: (0644/-rw-r--r--)  Uid: ( 1000/      pi)   Gid: ( 1000/      pi)
    Zugriff    : 2021-11-09 16:09:23.864745161 +0100
    Modifiziert: 2021-11-09 16:30:03.028555550 +0100
    Geändert   : 2021-11-09 16:30:03.028555550 +0100
     Geburt    : -

    In Datei1 steht eigentlich nur eine 0 oder 1, reingeschrieben wird das auch durch den Eintrag in der crontab:

    @reboot touch /dev/shm/datei1.txt && chown pi:pi /dev/shm/datei1.txt && /home/pi/datei1.sh

    In der datei1.sh steht auch nur:

    Bash
    #!/bin/sh
    echo "1" > /dev/shm/datei1.txt
    exit

    Das funktioniert ja auch alles wunderbar, nur irgendwann (über Nacht) ist die Datei plötzlich weg und ich weiss nicht warum oder woher. :conf:

    Was macht der Befehl sudo chattr +i /dev/shm/datei1.txt ?

  • Ok, sehe ich mit inotify dann noch die Versuche, die unternommen werden, die Datei zu löschen ?

    Das weiß ich nicht sicher, kann mir das aber nicht vorstellen. Wenn es geändert werden soll, dann muss wie geschrieben vorher chattr -i ... verwendet werden und deanach .... Das wäre trotzdem alles irgendwie Murks.

    Warum verwendest Du überhaupt /dev/shm als Speicherort, wenn Du eh als overlayfs mountest? Du kannst dann doch direkt nach /home/pi schreiben, denn dort landet es ja auch nur temporär im RAM. Oder wo ist mein Denkfehler? :conf:

  • Ok, sehe ich mit inotify dann noch die Versuche, die unternommen werden, die Datei zu löschen ?

    Eigentlich soll sie ja manchmal geändert werden können, der Inhalt der Datei von 1 auf 0 und umgekehrt, aber nie gelöscht werden.

    Wenn das i-Flag gesetzt ist, sieht man mit inotify die Löschversuche nicht. Es ist ja nicht als Lösung gedacht, sondern nur temporär als Test und für den Zeitraum, in dem diese Datei gelöscht wird. Wenn aber auch in diesem Zeitraum in die Datei geschrieben werden soll, kann mit dem gesetzten i-Flag nicht getestet werden.

    EDIT:

    Du könntest auf deinem PI auch auditd installieren und danach mit:

    Code
    auditctl -w /dev/shm/datei1.txt -p wa

    den Prozess finden bzw. überwachen, der auf diese Datei zugreift und/oder Änderungen an dieser Datei verursacht/hervorruft. Siehe dann die Eintragungen in der Datei "/var/log/audit/audit.log".

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden
    "Das dauert plötzlich ½ Sekunde länger. Das muss ich mir anschauen!" - Andres Freund

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.5 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p6 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, Mumble-Server, botamusique, ample

    Edited once, last by rpi444 (November 12, 2021 at 10:49 AM).

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!