Hallo Hans-Werner, * On Mon, Oct 31, 2005 at 09:09 PM (+0100), Hans-Werner Hilse wrote:
On Mon, 31 Oct 2005 18:07:31 +0100 Steffen Moser
wrote: Ich kann sonst nichts erkennen. Außerdem war ja wirklich in "messages" nichts mehr los nach dem "rotate". Und dass keiner der Dienste (auch der zunächst mehrfach neu gestartete LDAP-Daemon) gar nichts vom Syslog protokollieren ließ, wäre ja eher seltsam. Den "nscd" hatte ich am Sonn- tag übrigens auch mehrfach neu gestartet.
Einen hab' ich jetzt doch noch, und das wird abenteuerlich: hast du die Unix-Authentifizierung über das LDAP laufen, das der Rechner selbst über den besagten LDAP-Dienst anbietet?
Ja, das habe ich...
Dann könnten wir u.U. eine Art Race Condition haben.
Das könnte in der Tat sein. Du wirst lachen, ich hatte schon an eine Art "Race Condition" gedacht, was das Neustarten des Syslog betrifft, ich dachte aber gar nicht an den OpenLDAP, sondern eher daran, dass es vielleicht mit anderen Cron-Daily-Jobs Probleme gibt und hatte da- her gestern bei meinen Erzwungenen Cron-Daily-Läufen auch versucht, eben nicht nur "logrotate" auszuführen, sondern alle Cron-Daily-Ge- schichten. Aber das, was Du hier schreibst, ist ein hochinteressanter Aspekt, dem ich nachgehen werde.
Wenn dann nämlich der Neustart von syslog-ng eine Anfrage an das LDAP-Verzeichnis provoziert (z.B. Rechte des ausführenden Nutzers etc.pp.)
Wieso "syslog-ng" das tun sollte, ist mir zwar noch nicht ganz klar, aber ausschließen kann ich's nicht. "syslog-ng" läuft natürlich als "root" und "root" wird lokal verwaltet. Aber vielleicht ist es ja auch nur eine Anfrage im Rahmen von "nss_ldap", also z.B. die Auf- lösung irgend eines Namens (nein, die Hostnamen verwalte ich schon per DNS, aber vielleicht irgendwie "Benutzername <---> UID").
_und_ dabei der FIFO voll läuft _und_ dadurch dann OpenLDAP blockt, ja dann beißt sich die Katze in den Schwanz und nichts geht mehr (sprich, es hängt der Neustart des syslog-ng fest).
Auf jeden Fall schonmal vielen Dank für den Tipp, das muss ich un- bedingt näher untersuchen... Bei meinen Tests mit abgeschaltetem Syslog gestern Abend blieb das System übrigens über Stunden stabil. Ein "strace" von "/bin/logger" zeigte auch, dass es beim Versuch, "/dev/log" zu öffnen, während der Syslog abgeschaltet ist, einfach ein "Connection refused" gibt und "/bin/logger" dann halt nichts schreibt - und fertig. Es kam auf jeden Fall (selbst nach dem ich bei abgeschaltetem Sys- log in einer Endlosschleife den "/bin/logger" massiv loggen ließ) nicht zu einer Situation, wo "/bin/logger" in irgend einer Art und Weise auf das "/dev/log"-Socket gewartet hatte und sich dabei ver- klemmte. Das würde auf jeden Fall dagegen sprechen, dass der Syslog beim Auf- treten des Problems am Samstag und Sonntag "abgestellt" war. Er müsste zumindest noch soweit aktiv gewesen sein, dass Anwendungen versucht haben, nach "/dev/log" zu schreiben, also nicht schon gleich mit einem "Connection refused" abgewiesen wurden. Ich weiß leider zu wenig, wie "named sockets" funktionieren. Es gibt auch Unterschiede zwischen "named sockets" und FIFOs. Die "named sockets" haben ja ein "s" im "Spezialflag" des Dateisystems, während die FIFOs (oder auch "named pipes") ein "p" haben: | steffen@pc01:~> ll /dev/log | srw-rw-rw- 1 root root 0 2005-10-15 20:08 /dev/log Ich versuche jetzt einmal abzuklären, ob es tatsächlich zu einer "Race Condition" kommen kann. So nach dem Motto: Der Syslog will reloaden. Er läuft dabei. Er muss aber zum Reload -aus welchem Grund auch immer- den OpenLDAP fragen. Dieser will daraufhin auch antworten, aber loggt natürlich erstmal. Da der Syslog noch läuft, kriegt der OpenLDAP auch kein "Connection refused" beim Öffnen des Log-Sockets. Also schreibt der OpenLDAP ins Log-Socket, aber auf der anderen Seite liest niemand raus, und OpenLDAP hängt fest. Der Syslog kommt dann nie zu seiner angeforder- ten Antwort. Dem gehe ich nachher einmal nach... Es muss ja auch gar nicht unbe- dingt "OpenLDAP" sein, sondern evtl. ein ganz anderer Prozess, der dann den Syslog blockiert. Viele Grüße, Steffen