Thomas Antepoth <[EMAIL PROTECTED]> writes: > Hallo Bruno, :-) > > > On Wed, 30 Mar 2005, Bruno Hertz wrote: > >> Thomas Antepoth <[EMAIL PROTECTED]> writes: >> > [ Logfiles in near-realtime parsen ] >> OK, unter Perl w�re die Vorgehensweise vielleicht wie folgt: >> * anstatt einer read loop eine select loop mit timeout >> * in jeder Iteration mit stat pr�fen ob sich der inode meiner Datei >> ge�ndert hat >> * wenn ja, file neu �ffnen. >> Oder? > > Ganz genau so mu� es funktionieren. > > Gerade habe ich ein wenig ge"apt-cache"d. Hierbei fand sich dann > "libfile-tail-perl", welches genau dies macht. Ich konnte mir auch ehrlich > gesagt nicht vorstellen, dass dieses Basisproblem nicht schon von > irgendeinem Menschen auf dem Planeten gel�st wurde. > > Das gef�llt mir dann doch viel besser als alle "tail --retry -n ..." > Backtick-Wurschdeleien. > > Das auf "File::Tail" angepasste Script findet sich a.a.O. - der > diff dazu findet sich bei http://212.227.20.60/debian/denyssh.diff > > Herzlichen Dank noch f�r den Denkansto� und ein sch�nes Wochenende! :-) > t++
Gleichfalls, vielen Dank :) Das Problem ist �brigens klassisch, insbesondere auch f�r C Programmierer. I.e. wenn du ein 'open' auf eine Datei machst, kriegst du einen descriptor der valid ist auch wenn die Datei von einem anderen Prozess entfernt wird. D.h. die Datei ist in Wirklichkeit noch da, du kannst sie noch immer lesen und in sie schreiben, sie ist halt nur nicht mehr im Dateisystem sichtbar und wird eben in Wirklichkeit erst entfernt wenn kein Prozess mehr einen offenen file descriptor auf sie h�lt. All das ist sehr sch�n, aber es n�tzt dir nat�rlich nichts wenn du selbst aus der Datei lesen willst was andere Prozesse in sie schreiben, diese aber bereits eine neue Datei verwenden. Das andere Thema, i.e. 'read' und 'select' ist fast noch klassischer. I.e. in der Regel blockiert ein read auf einem descriptor solange bis Daten zum Lesen eintreffen, was recht lange dauern kann insbesondere wenn keiner mehr in die zugeh�rige Datei schreibt :) Man kann zwar nun, wenn man regelm��ig andere Bedingungen abpr�fen will wie den Zustand der Datei, den read nonblocking setzen, aber das w�rde auf eine busy loop hinauslaufen solange keine Daten eintreffen, was nat�rlich unerw�nscht ist. Die Standardl�sung ist eben 'select', das den Prozess ebenso h�bsch schlafen legt wie read wenn keine Daten da sind, aber wo man zus�tzlich ein timeout setzen kann, was bei read alleine eben nicht m�glich ist. In summa ist also die ganze Thematik, vom programmiertechnischen Standpunkt aus, wirklich ein sehr typischer Standardfall :) Gruss, Bruno.
