Frage

Ich schreibe einen inotify-Beobachter in C für einen Minecraft-Server.Grundsätzlich überwacht es server.log, ruft die neueste Zeile ab, analysiert sie und stimmt mit einem regulären Ausdruck überein.führt einige Aktionen aus.

Das Programm funktioniert einwandfrei über "Echo-String, der mit dem regulären Ausdruck >> server.log übereinstimmt". Es analysiert und tut, was es sollte.Wenn die Zeichenfolge jedoch automatisch über den Minecraft-Server in die Datei geschrieben wird, funktioniert sie erst, wenn ich den Server heruntergefahren oder mich (manchmal) abgemeldet habe.

Ich würde Code posten, aber ich frage mich, ob es nichts damit zu tun hat, dass ext4 Daten auf die Festplatte spült oder etwas in dieser Richtung.ein Dateisystemproblem.Es wäre jedoch seltsam, wenn dies der Fall wäre, da "tail -f server.log" immer dann aktualisiert wird, wenn die Datei dies tut.

War es hilfreich?

Lösung

Mein eigenes Problem gelöst.Es stellte sich heraus, dass der Server schneller in die Protokolldatei schrieb, als der Beobachter daraus lesen konnte.Der Beobachter war also nicht mehr synchron.

Ich habe es behoben, indem ich nach der Verarbeitung des Ereignisses eine Prüfung hinzugefügt habe, die besagt: "Wenn die Anzahl der aktuell in der Protokolldatei enthaltenen Zeilen größer als die aufgezeichnete Länge des Protokolls ist, verarbeiten Sie die Datei erneut, bis beide gleich sind."

Danke für Ihre Hilfe!

Andere Tipps

Vermutlich liegt dies daran, dass Sie nach IN_CLOSE-Ereignissen suchen, die möglicherweise erst auftreten, wenn der Server heruntergefahren wird (und das Handle der Protokolldatei schließt).Gültige Maskenparameter finden Sie unter man inotify (7) für den inotify_add_watch()-Aufruf.Ich gehe davon aus, dass Sie IN_WRITE verwenden möchten.

Ihre Theorie ist mehr als wahrscheinlich richtig, die Protokolldatei wird vom Betriebssystem gepuffert, und der Protokollschreiber hat keine Leerung dieses Puffers, sodass alles im Puffer verbleibt, bis die Datei geschlossen oder der Puffer voll ist.Eine schnelle Möglichkeit zum Testen besteht darin, das Protokoll bis zu dem Punkt zu starten, an dem Sie wissen, dass Ereignisse in das Protokoll geschrieben wurden, und es dann zwangsweise zu schließen, damit das Handle nicht geschlossen werden kann, wenn das Protokoll leer ist. Dies ist definitiv der Puffer.Wenn Sie das Dateihandle / Deskriptor erhalten können, können Sie setbuf verwenden, um die Pufferung auf Kosten der Leistung zu entfernen.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top