Zu Debug-Zwecken möchte ich den Inhalt einer Datei möglichst zeitnah (im ms-Bereich) überwachen.
Es gibt tatsächlich zwei Prozesse die lesend und schreiben darauf zugreifen. Um das besser zu durchschauen, möchte ich das gerne live beobachten.
EDIT: watch -n 0.1 ist zu langsam. Wenn ich so darüber nachdenke, wäre vielleicht weniger eine live-Beobachtung, sondern mehr eine Art Protokollierung sinnvoller. Mhm... Oder ich haue mal ein paar sleep() Befehle in den Code, um den Prozess auszubremsen.
[Gelöst] Inhalt einer Textdatei in "Echtzeit" beobachten
[Gelöst] Inhalt einer Textdatei in "Echtzeit" beobachten
Zuletzt geändert von buhtz am 26.02.2024 14:36:13, insgesamt 1-mal geändert.
Debian 11 & 12; Desktop-PC, Headless-NAS, Raspberry Pi 4
Teil des Upstream Betreuer Teams von Back In Time (backintime)
Teil des Upstream Betreuer Teams von Back In Time (backintime)
Re: Inhalt einer Textdatei in "Echtzeit" beobachten
Ohne weitere Details würde ich da einfach an tail -f oder inotifywait denken.
Je nachdem, was du bei Änderungen machen möchtest, kann auch ein eigenes, kleines Programm (inotify benutzend) sinnvoll sein.
Je nachdem, was du bei Änderungen machen möchtest, kann auch ein eigenes, kleines Programm (inotify benutzend) sinnvoll sein.
Manchmal bekannt als Just (another) Terminal Hacker.
- heisenberg
- Beiträge: 3666
- Registriert: 04.06.2015 01:17:27
- Lizenz eigener Beiträge: MIT Lizenz
Re: Inhalt einer Textdatei in "Echtzeit" beobachten
Was ist denn das eigentliche Problem?
Wenn ich lese, dass da zwei Programme auf die gleiche Datei zugreifen, dann frage ich mich spontan, ob die Art und Weise des Schreibens sauber durchgeführt wird.
Konkret
Findet ein Locking statt?
Sind das atomare Writes (d. h. werden Änderungen durch Schreiben einer temporären Datei auf dem gleichen FS und anschließendem Verschieben)?
Ist das nicht der Fall, kann man davon ausgehen, dass es eigentlich schief laufen muss. (z. B. in der Art, dass eine lesende Anwendung regelmäßig unvollständige Daten erhält.)
Wenn ich lese, dass da zwei Programme auf die gleiche Datei zugreifen, dann frage ich mich spontan, ob die Art und Weise des Schreibens sauber durchgeführt wird.
Konkret
Findet ein Locking statt?
Sind das atomare Writes (d. h. werden Änderungen durch Schreiben einer temporären Datei auf dem gleichen FS und anschließendem Verschieben)?
Ist das nicht der Fall, kann man davon ausgehen, dass es eigentlich schief laufen muss. (z. B. in der Art, dass eine lesende Anwendung regelmäßig unvollständige Daten erhält.)
Zuletzt geändert von heisenberg am 26.02.2024 14:35:15, insgesamt 1-mal geändert.
Re: Inhalt einer Textdatei in "Echtzeit" beobachten
+1 für inotifywait.
Jesus saves. Buddha does incremental backups.
Windows ist doof, Linux funktioniert nicht • Don't break debian! • Wie man widerspricht
Windows ist doof, Linux funktioniert nicht • Don't break debian! • Wie man widerspricht
Re: Inhalt einer Textdatei in "Echtzeit" beobachten
Live-Beobachtung in Millisekundengeschwindigkeit waere auch recht herausforderungsvoll fuer Menschen.buhtz hat geschrieben:26.02.2024 14:03:24Wenn ich so darüber nachdenke, wäre vielleicht weniger eine live-Beobachtung, sondern mehr eine Art Protokollierung sinnvoller.
Du koennest in einer Endlosschleife `git commit' auf die Datei machen, dann kannst du danach die Git-Historie als Protokoll nutzen.
Use ed once in a while!
Re: Inhalt einer Textdatei in "Echtzeit" beobachten
Prima, das geht auch gut.
Da ist kein (technisches) Problem. Ich versuche nur Anwendungs-Verhalten zu dokumentieren, was die ursprünglichen Entwickler "vergessen" haben.
Wirklich geile Idee!Meillo hat geschrieben:26.02.2024 14:33:33Du koennest in einer Endlosschleife `git commit' auf die Datei machen, dann kannst du danach die Git-Historie als Protokoll nutzen.
Debian 11 & 12; Desktop-PC, Headless-NAS, Raspberry Pi 4
Teil des Upstream Betreuer Teams von Back In Time (backintime)
Teil des Upstream Betreuer Teams von Back In Time (backintime)
Re: Inhalt einer Textdatei in "Echtzeit" beobachten
Ha, das klingt gutMeillo hat geschrieben:26.02.2024 14:33:33Du koennest in einer Endlosschleife `git commit' auf die Datei machen, dann kannst du danach die Git-Historie als Protokoll nutzen.
Manchmal bekannt als Just (another) Terminal Hacker.