Mailinglist Archive: opensuse-de (1905 mails)

< Previous Next >
Re: NFS: Probleme mit lockd [gelöst]
  • From: Lars Ziegler <lziegler@xxxxxxxxx>
  • Date: Sat, 26 Jan 2008 20:26:00 +0100
  • Message-id: <479B8948.3080205@xxxxxxxxx>
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.mbox.txt



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@xxxxxxxxxxxx
Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken
Sie eine Mail an: opensuse-de+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups