fragen zu named pipes / bessere ideen gefragt...

[tassilo]

moin moin

hoffe mal hier bin ich richtig. wollte erst ins unixforum schreiben aber hab den eindruck das sich sowieso die meistens in beiden foren tummeln.

ich habe folgendes problem das ich viele verschiedene software betreuen soll , hauptsächlich das logging.
manch eine software schreibt selbst logfiles, manch eine nicht. das problem ist das die programme *nicht* beendet werden dürfen also fällt z.b. "logrotate" flach.
auch möchte ich verhindern das logfiles recht gross werden. Manch ein dienst schreibt hier 30-40gb logs in ein file pro tag.

meine idee ist hier einfach named pipes zu benutzen.
für jede software/dienst eine pipe gemacht einen kleinen server in c geschrieben der von der pipe liest und das dann auf platte schreibt, das progrämmchen kann dann auch noch gleich die files mit nem datumstempel versehen und z.b. alle 100mb (z.b.) das logfile "splitten".
named pipes deswegen da ich ja keinen zugriff auf die von mir verwalteten programme als sourcen habe und so ne pipe generell für alle linuxe, solaris, aix rechner einfach ein file ist in das man reinschreiben kann..

soweit so gut. mein problem ist nun

sollte mein kleiner server der von der named pipe liest aus welchen grund auch immer sterben blockt das die ganzen dienste bis wieder von der pipe gelesen wird.  stimmt das so? jedenfalls war das bei meinen tests immer der fall.
gibts ne möglichkeit das sozusagen zu "buffern" bis der server wieder da ist? (man könnte ja als cron einen check laufen lassen der jede minute guckt ob der "wegschreibprozess" noch da ist und lebt...)

oder gehe ich das alles falsch an?
über tipps / hinweise wär ich dankbar.

ach ja meine "resourcen" sind eigentlich nur diese 2 links :

http://www.tldp.org/LDP/lpg/node15.html
http://developers.sun.com/solaris/articles/named_pipes.html
(und das buch "advanced system programming" das ich angefangen habe durchzuarbeiten aber bis jetzt steht da auch nichts anderes drin als in den o.g. links)

grüße

tassilo

[Toktar]

Was hast Du gegen Syslog?

[tassilo]

hallo

weil logrotate (das das ich kenne) den prozess beendet, das file umbenennt, prozess wieder startet.
das ist die standart vorgehensweise. das darf nicht passieren da die prozesse nicht beendet werden dürfen.

es gibt noch die möglichkeit das wechseln des files mit irgendwelchen signalen den prozessen zu sagen, das muss die software aber unterstützen. tut sie aber nicht.

das kopieren des files und danach auf null setzen ist -imho- verlustbehaftet.

aber wie gesagt ich lasse mich gerne eines besseren belehren.

grüße

tassilo

[tassilo]

man man man. du schreibst syslog ich lese logrotate. sorry zu viele dinge gleichzeitig am erledigen.
für syslog braucht man -imho- rootrechte die haben wir nicht, sind gemanaged systeme. aber ja syslog ich gucks mir mal an.

grüße tassilo

kurzes edit :

also mal kurz gegoogelt ... um an den syslogd zu schreiben muss das programm das auch unterstützten. wenn nicht gibts tools dafür aber dann sind wir wieder bei meiner lösung.

[Ten Little Indyans]

sollte mein kleiner server der von der named pipe liest aus welchen grund auch immer sterben blockt das die ganzen dienste bis wieder von der pipe gelesen wird.  stimmt das so? jedenfalls war das bei meinen tests immer der fall.
gibts ne möglichkeit das sozusagen zu "buffern" bis der server wieder da ist?

Nach meinem Verständnis könnte der schreibende Prozess die Pipe als non-blocking öffnen (O_NONBLOCK). Dann hat er zumindest ein paar Kilobyte Luft in denen sich ein neuer Abnehmer finden muss. Aus Deiner zweiten Resource:

Similarly if a process tries to write to a named pipe that has no reader, the writing process gets blocked, until another process opens the named pipe for reading. This, of course, can be overridden by specifying the O_NONBLOCK flag while opening the named pipe.

Das fällt natürlich flach wenn Du keine Sourcen hast um das O_NONBLOCK dort einzubauen.

Ganz anderer Ansatz: Wie reagieren diese Programme wenn man ihnen das Logfile unterm Hintern weglöscht?

(a) sie haben das Logfile dauerhaft zum schreiben geöffnet und schreiben somit weiter in die gelöschte Datei. [Solange ein Prozess eine Datei geöffnet hat wird ihr Platz nicht freigegeben, sondern nur der Directory-Eintrag entfernt]

(b) sie öffnen und schliessen das Logfile bei jedem Schreibvorgang, oder zumindest regelmäßig und sind so nett es einfach neu anzulegen wenn es fehlt.

Wenn (b) zutrifft könnte man im eigenen Code wie folgt vorgehen:
1. Datei zum Lesen öffnen
2. Datei löschen (unlink). Beim nächsten Schreibversuch sollte das loggende Programm eine neue Datei anlegen. Über den offenen Filehandle haben wir aber noch Zugriff auf die alte Datei.
3. Aus der geöffneten Datei lesen und wegsichern
4. Datei schliessen. Erst jetzt wird ihr Speicherplatz wieder freigegeben.
5. Nach gewisser Zeit wieder zu Schritt 1.

[tassilo]

Nach meinem Verständnis könnte der schreibende Prozess die Pipe als non-blocking öffnen (O_NONBLOCK). Dann hat er zumindest ein paar Kilobyte Luft in denen sich ein neuer Abnehmer finden muss. Aus Deiner zweiten Resource:

Similarly if a process tries to write to a named pipe that has no reader, the writing process gets blocked, until another process opens the named pipe for reading. This, of course, can be overridden by specifying the O_NONBLOCK flag while opening the named pipe.

Das fällt natürlich flach wenn Du keine Sourcen hast um das O_NONBLOCK dort einzubauen.

ja das ist das problem. ich habe keinen zugriff auf die sourcen.

Ganz anderer Ansatz: Wie reagieren diese Programme wenn man ihnen das Logfile unterm Hintern weglöscht?

(a) sie haben das Logfile dauerhaft zum schreiben geöffnet und schreiben somit weiter in die gelöschte Datei. [Solange ein Prozess eine Datei geöffnet hat wird ihr Platz nicht freigegeben, sondern nur der Directory-Eintrag entfernt]

leider version a) ...

grüße

tassilo

[dominik]

Als "Erleichterung" bei dem Problem könntest Du versuchen, das Logfile auf ein ZVOL mit eingeschalteter Kompression zu legen. Ich könnte mir vorstellen, dass dadurch die Situation etwas entschärft würde.

Gruss
Dominik