Sandy Drobic schrieb:
Lars Ziegler wrote:
Sandy Drobic schrieb:
Lars Ziegler wrote:
Sandy Drobic schrieb:
Wie sieht es eigentlich mit den Anwendungen aus, nutzen diese alle den gleichen Locking-Mechanismus?
Wie kann man das feststellen? Welche Lock-Mechanismen gibt es denn eigentlich alles? http://www.postfix.org/NFS_README.html Postfix kennt zwei Arten (dotlock und fcntl), daneben gibt es noch einige andere. Dotlock legt imho eine "dateiname.lock" an, um das Locking zu verwalten.
Wie man in diesem README bereits sieht, kommt es durchaus zu Problemen im Zusammenhang mit verschiedenen Kernen. Was war denn der Grund, von einem (funktionierenden?) 10.2 nach 10.3 zu wechseln? Das frag ich mich inzwischen auch! Ich hatte damals auch einen neuen Kernel kompiliert, weil irgendwas nicht funktioniert hatte (keine Ahnung mehr was das war; hatte aber nichts mit dem Locking zu tun) darauf hin konnte ich dann keinen neuen SuSE-Updates mehr einspielen. Das hat mich einfach gestört. Daher der Wechsel.
Grins! Better the devil you know...
Hier ist ein Link, der die Locking-Mechanismen und deren Reihenfolge etwas tiefer betrachtet: http://www.mcs.vuw.ac.nz/technical/software/doc/dovecot/wiki/MailboxFormat.m...
Trotzdem bin ich nicht unbedingt überzeugt, dass dies etwas damit zu tun hat, wenn das Locking fehlschlägt, weil lockd keine Datei anlegen kann. Die obigen Tipps sind eher etwas dafür, wenn das Locking nicht sauber funktioniert und man deswegen Datenkorruption erhält.
Ich fürchte, dass es wirklich ein Problem beim Zusammenspiel mit dem Kernel ist. :-/
Welches Locking die Programme verwenden, konnte ich noch nicht herausfinden. In meiner /etc/postfix/main.cf steht überhaupt nichts über das verwendete Locking.
Wenn dort nichts drin steht, gilt der Default:
# postconf | grep _lock deliver_lock_attempts = 20 deliver_lock_delay = 1s mailbox_delivery_lock = fcntl, dotlock stale_lock_time = 500s virtual_mailbox_lock = fcntl, dotlock
Also ich hab jetzt mal deine letzten Tipps ausprobiert und in die Datei /etc/security/limits.conf folgenden Eintrag vorgenommen:
* soft nofiles 4096
Sorry, mein Fehler, ohne das "s":
* soft nofile 4096
Ein Neustart ist nicht erforderlich, die Einstellung wird nach kurzer Zeit übernommen, zumindest war dies bei mir so. Vermutlich ein Cron-Job, der dies mit exportiert.
Ich werde heute Mittag mal ausprobieren, ob sich was geändert hat, nachdem es gestern ausnahmsweise mal funktioniert hat. Allerdings was mich wundert, wenn ich mir über ulimit -n das Limit anzeigen lass, stehen da immer noch 1024 statt 4096. Wenn ich per Hand ulimit -n 4096 eingeben und dann das Limit anzeigen lasse, steht da zwar 4096, aber sobald ich das auf einer anderen Konsole mach, steht da wiederum nur 1024.
Logisch, weil der Befehl dies nur für die aktuelle Bash einstellt.
ich hab jetzt die Lösung für das Problem gefunden. Die Ursache war nicht der Server, sondern die Clients. Deren Netzwerkkarten waren in der Firewall der externen Zone zugewiesen. Die Folge war, dass einige Netzwerkpakete verloren gegangen sind. Der Server konnte damit seine Lock-Prozesse nicht fertig stellen, wodurch der Locking-Dienst ausgebremst wurde. Jetzt hab ich die Netzwerkkarten der internen Zone zugewiesen, und es funktioniert. Zumindest bis jetzt. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org