Hallo alle zusammen,
ich hab einen Server mit Opensuse 10.3 (inkl. aller Updates) laufen. Der Server ist NFS-Server, Mail-Server, Proxy-Server und Anmelde-Server (Openldap). Im Netzwerk befinden sich ca. 70 Linux-Clients (OpensSuSE 10.3).
Wenn sich zu viele Benutzer anmelden (KDE), reagiert plötzlich kein Linux-Client mehr und man kann auf der Konsole ein Timeout für lockd sehen. Der Fehler ist nur zu beheben, wenn man den Server neu starten, oder den NFS-Server stoppt, die Module nfsd und lockd neu lädt und den NFS-Server wieder startet. Allerdings ist der Erfolg immer nur von kurzer Dauer. Die Meldungen auf dem Server lauten
lockd: couldn't create rpc handle kernel: statd: server localhost not responding, timed out
Der Befehl rpcinfo -u localhost 100021 ergibt dann einen Timout-Error. Ich hab auch schon einen neuen Kernel aus der OS-Factory-Version probiert, aber es hat nichts geholfen.
Viele Dank für eure Hilfe
Lars Ziegler wrote:
Hallo alle zusammen,
ich hab einen Server mit Opensuse 10.3 (inkl. aller Updates) laufen. Der Server ist NFS-Server, Mail-Server, Proxy-Server und Anmelde-Server (Openldap). Im Netzwerk befinden sich ca. 70 Linux-Clients (OpensSuSE 10.3).
Wenn sich zu viele Benutzer anmelden (KDE), reagiert plötzlich kein Linux-Client mehr und man kann auf der Konsole ein Timeout für lockd sehen. Der Fehler ist nur zu beheben, wenn man den Server neu starten, oder den NFS-Server stoppt, die Module nfsd und lockd neu lädt und den NFS-Server wieder startet. Allerdings ist der Erfolg immer nur von kurzer Dauer. Die Meldungen auf dem Server lauten
lockd: couldn't create rpc handle kernel: statd: server localhost not responding, timed outDer Befehl rpcinfo -u localhost 100021 ergibt dann einen Timout-Error. Ich hab auch schon einen neuen Kernel aus der OS-Factory-Version probiert, aber es hat nichts geholfen.
Wahrscheinlich hat der lockd keine file handles mehr anlegen dürfen.
Was steht den in /etc/security/limits.conf? Unter welchem User läuft lockd?
Sandy Drobic schrieb:
Lars Ziegler wrote:
Hallo alle zusammen,
ich hab einen Server mit Opensuse 10.3 (inkl. aller Updates) laufen. Der Server ist NFS-Server, Mail-Server, Proxy-Server und Anmelde-Server (Openldap). Im Netzwerk befinden sich ca. 70 Linux-Clients (OpensSuSE 10.3).
Wenn sich zu viele Benutzer anmelden (KDE), reagiert plötzlich kein Linux-Client mehr und man kann auf der Konsole ein Timeout für lockd sehen. Der Fehler ist nur zu beheben, wenn man den Server neu starten, oder den NFS-Server stoppt, die Module nfsd und lockd neu lädt und den NFS-Server wieder startet. Allerdings ist der Erfolg immer nur von kurzer Dauer. Die Meldungen auf dem Server lauten
lockd: couldn't create rpc handle kernel: statd: server localhost not responding, timed outDer Befehl rpcinfo -u localhost 100021 ergibt dann einen Timout-Error. Ich hab auch schon einen neuen Kernel aus der OS-Factory-Version probiert, aber es hat nichts geholfen.
Wahrscheinlich hat der lockd keine file handles mehr anlegen dürfen.
Was steht den in /etc/security/limits.conf? Unter welchem User läuft lockd?
Also wenn mich nicht alles täuscht läuft lockd zusammen mit dem nfsserver unter dem root-Benutzer. In Datei steht eigentliche nur auskommentiertes drin:
/# /etc/security/limits.conf/ /#/ /#Each line describes a limit for a user in the form:/ /#/ /#<domain> <type> <item> <value>/ /#/ /#Where:/ /#<domain> can be:/ /# - an user name/ /# - a group name, with @group syntax/ /# - the wildcard *, for default entry/ /# - the wildcard %, can be also used with %group syntax,/ /# for maxlogin limit/ /#/ /#<type> can have the two values:/ /# - "soft" for enforcing the soft limits/ /# - "hard" for enforcing hard limits/ /#/ /#<item> can be one of the following:/ /# - core - limits the core file size (KB)/ /# - data - max data size (KB)/ /# - fsize - maximum filesize (KB)/ /# - memlock - max locked-in-memory address space (KB)/ /# - nofile - max number of open files/ /# - rss - max resident set size (KB)/ /# - stack - max stack size (KB)/ /# - cpu - max CPU time (MIN)/ /# - nproc - max number of processes/ /# - as - address space limit (KB)/ /# - maxlogins - max number of logins for this user/ /# - maxsyslogins - max number of logins on the system/ /# - priority - the priority to run user process with/ /# - locks - max number of file locks the user can hold/ /# - sigpending - max number of pending signals/ /# - msgqueue - max memory used by POSIX message queues (bytes)/ /# - nice - max nice priority allowed to raise to/ /# - rtprio - max realtime priority/ /#/ /#<domain> <type> <item> <value>/ /#/
/#* soft core 0/ /#* hard rss 10000 / /#@student hard nproc 20/ /#@faculty soft nproc 20/ /#@faculty hard nproc 50/ /#ftp hard nproc 0/ /#@student - maxlogins 4/
/# End of file/
Kann das denn dazu führen, dass der lockd abstürzt, wenn keine file handles mehr angelegt werden dürfen?
Lars Ziegler wrote:
Sandy Drobic schrieb:
Lars Ziegler wrote:
Hallo alle zusammen,
ich hab einen Server mit Opensuse 10.3 (inkl. aller Updates) laufen. Der Server ist NFS-Server, Mail-Server, Proxy-Server und Anmelde-Server (Openldap). Im Netzwerk befinden sich ca. 70 Linux-Clients (OpensSuSE 10.3).
Wenn sich zu viele Benutzer anmelden (KDE), reagiert plötzlich kein Linux-Client mehr und man kann auf der Konsole ein Timeout für lockd sehen. Der Fehler ist nur zu beheben, wenn man den Server neu starten, oder den NFS-Server stoppt, die Module nfsd und lockd neu lädt und den NFS-Server wieder startet. Allerdings ist der Erfolg immer nur von kurzer Dauer. Die Meldungen auf dem Server lauten
lockd: couldn't create rpc handle kernel: statd: server localhost not responding, timed outDer Befehl rpcinfo -u localhost 100021 ergibt dann einen Timout-Error. Ich hab auch schon einen neuen Kernel aus der OS-Factory-Version probiert, aber es hat nichts geholfen.
Wahrscheinlich hat der lockd keine file handles mehr anlegen dürfen.
Was steht den in /etc/security/limits.conf? Unter welchem User läuft lockd?
Also wenn mich nicht alles täuscht läuft lockd zusammen mit dem nfsserver unter dem root-Benutzer.
Okay...
In Datei steht eigentliche nur auskommentiertes drin:
Dann solltest du vielleicht die Grenzen anpassen. "ulimit -a" zeigt die Einstellungen. Dein Problem wird vermutlich durch "ulimit -n" gezeigt.
Kann das denn dazu führen, dass der lockd abstürzt, wenn keine file handles mehr angelegt werden dürfen?
Ich vermute, dass er (NFS) nicht abstürzt, sondern hängt, während er auf Antwort von lockd wartet.
Hebe die limits an, dann sollte das Problem zuende sein, wenn der Server das verkraftet.
Sandy Drobic schrieb:
Lars Ziegler wrote:
Sandy Drobic schrieb:
Lars Ziegler wrote:
Hallo alle zusammen,
ich hab einen Server mit Opensuse 10.3 (inkl. aller Updates) laufen. Der Server ist NFS-Server, Mail-Server, Proxy-Server und Anmelde-Server (Openldap). Im Netzwerk befinden sich ca. 70 Linux-Clients (OpensSuSE 10.3).
Wenn sich zu viele Benutzer anmelden (KDE), reagiert plötzlich kein Linux-Client mehr und man kann auf der Konsole ein Timeout für lockd sehen. Der Fehler ist nur zu beheben, wenn man den Server neu starten, oder den NFS-Server stoppt, die Module nfsd und lockd neu lädt und den NFS-Server wieder startet. Allerdings ist der Erfolg immer nur von kurzer Dauer. Die Meldungen auf dem Server lauten
lockd: couldn't create rpc handle kernel: statd: server localhost not responding, timed outDer Befehl rpcinfo -u localhost 100021 ergibt dann einen Timout-Error. Ich hab auch schon einen neuen Kernel aus der OS-Factory-Version probiert, aber es hat nichts geholfen.
Wahrscheinlich hat der lockd keine file handles mehr anlegen dürfen.
Was steht den in /etc/security/limits.conf? Unter welchem User läuft lockd?
Also wenn mich nicht alles täuscht läuft lockd zusammen mit dem nfsserver unter dem root-Benutzer.
Okay...
In Datei steht eigentliche nur auskommentiertes drin:
Dann solltest du vielleicht die Grenzen anpassen. "ulimit -a" zeigt die Einstellungen. Dein Problem wird vermutlich durch "ulimit -n" gezeigt.
Kann das denn dazu führen, dass der lockd abstürzt, wenn keine file handles mehr angelegt werden dürfen?
Ich vermute, dass er (NFS) nicht abstürzt, sondern hängt, während er auf Antwort von lockd wartet.
Hebe die limits an, dann sollte das Problem zuende sein, wenn der Server das verkraftet.
Also ulimit -x zeigt:
core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 41984 max locked memory (kbytes, -l) 32 max memory size (kbytes, -m) 3497835 open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 41984 virtual memory (kbytes, -v) 4975680 file locks (-x) unlimited
open files lässt sich allerdings nicht auf unlimited setzen. Also verkraften sollte der Server das schon (2x Dual-Core-Opteron, 4GB Speicher, 4 SCSI-HDD im Raid 5 (Hardware) Modus). Ich dachte, dass er abstürzt. Allerdings wenn man über ps -A alle laufenden Programme anzeigen lässt, steht hinter lockd zumindest nicht <defunct>.
Lars Ziegler wrote:
Sandy Drobic schrieb:
Lars Ziegler wrote:
Sandy Drobic schrieb:
Lars Ziegler wrote:
Hallo alle zusammen,
ich hab einen Server mit Opensuse 10.3 (inkl. aller Updates) laufen. Der Server ist NFS-Server, Mail-Server, Proxy-Server und Anmelde-Server (Openldap). Im Netzwerk befinden sich ca. 70 Linux-Clients (OpensSuSE 10.3).
Wenn sich zu viele Benutzer anmelden (KDE), reagiert plötzlich kein Linux-Client mehr und man kann auf der Konsole ein Timeout für lockd sehen. Der Fehler ist nur zu beheben, wenn man den Server neu starten, oder den NFS-Server stoppt, die Module nfsd und lockd neu lädt und den NFS-Server wieder startet. Allerdings ist der Erfolg immer nur von kurzer Dauer. Die Meldungen auf dem Server lauten
lockd: couldn't create rpc handle kernel: statd: server localhost not responding, timed outDer Befehl rpcinfo -u localhost 100021 ergibt dann einen Timout-Error. Ich hab auch schon einen neuen Kernel aus der OS-Factory-Version probiert, aber es hat nichts geholfen.
Wahrscheinlich hat der lockd keine file handles mehr anlegen dürfen.
Was steht den in /etc/security/limits.conf? Unter welchem User läuft lockd?
Also wenn mich nicht alles täuscht läuft lockd zusammen mit dem nfsserver unter dem root-Benutzer.
Okay...
In Datei steht eigentliche nur auskommentiertes drin:
Dann solltest du vielleicht die Grenzen anpassen. "ulimit -a" zeigt die Einstellungen. Dein Problem wird vermutlich durch "ulimit -n" gezeigt.
Kann das denn dazu führen, dass der lockd abstürzt, wenn keine file handles mehr angelegt werden dürfen?
Ich vermute, dass er (NFS) nicht abstürzt, sondern hängt, während er auf Antwort von lockd wartet.
Hebe die limits an, dann sollte das Problem zuende sein, wenn der Server das verkraftet.
Also ulimit -x zeigt:
nicht "ulimit -a"?
core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 41984 max locked memory (kbytes, -l) 32 max memory size (kbytes, -m) 3497835 open files (-n) 1024
Das scheint die einzige Engstelle zu sein. Hebe das doch mal auf 4096 für root.
root soft nofiles 4096
Im laufenden Betrieb geht das auch, aber AFAIK nur für die Shell, in der du als root eingeloggt bist. ulimit -n 4096
open files lässt sich allerdings nicht auf unlimited setzen. Also verkraften sollte der Server das schon (2x Dual-Core-Opteron, 4GB Speicher, 4 SCSI-HDD im Raid 5 (Hardware) Modus).
Ja, da sollten auch noch mehr offene Dateien kein Problem sein. Teste es mal.
Lars Ziegler schrieb:
Sandy Drobic schrieb:
Lars Ziegler wrote:
Sandy Drobic schrieb:
Lars Ziegler wrote:
Hallo alle zusammen,
ich hab einen Server mit Opensuse 10.3 (inkl. aller Updates) laufen. Der Server ist NFS-Server, Mail-Server, Proxy-Server und Anmelde-Server (Openldap). Im Netzwerk befinden sich ca. 70 Linux-Clients (OpensSuSE 10.3).
Wenn sich zu viele Benutzer anmelden (KDE), reagiert plötzlich kein Linux-Client mehr und man kann auf der Konsole ein Timeout für lockd sehen. Der Fehler ist nur zu beheben, wenn man den Server neu starten, oder den NFS-Server stoppt, die Module nfsd und lockd neu lädt und den NFS-Server wieder startet. Allerdings ist der Erfolg immer nur von kurzer Dauer. Die Meldungen auf dem Server lauten
lockd: couldn't create rpc handle kernel: statd: server localhost not responding, timed outDer Befehl rpcinfo -u localhost 100021 ergibt dann einen Timout-Error. Ich hab auch schon einen neuen Kernel aus der OS-Factory-Version probiert, aber es hat nichts geholfen.
Wahrscheinlich hat der lockd keine file handles mehr anlegen dürfen.
Was steht den in /etc/security/limits.conf? Unter welchem User läuft lockd?
Also wenn mich nicht alles täuscht läuft lockd zusammen mit dem nfsserver unter dem root-Benutzer.
Okay...
In Datei steht eigentliche nur auskommentiertes drin:
Dann solltest du vielleicht die Grenzen anpassen. "ulimit -a" zeigt die Einstellungen. Dein Problem wird vermutlich durch "ulimit -n" gezeigt.
Kann das denn dazu führen, dass der lockd abstürzt, wenn keine file handles mehr angelegt werden dürfen?
Ich vermute, dass er (NFS) nicht abstürzt, sondern hängt, während er auf Antwort von lockd wartet.
Hebe die limits an, dann sollte das Problem zuende sein, wenn der Server das verkraftet.
Also ulimit -x zeigt:
core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 41984 max locked memory (kbytes, -l) 32 max memory size (kbytes, -m) 3497835 open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 41984 virtual memory (kbytes, -v) 4975680 file locks (-x) unlimited
open files lässt sich allerdings nicht auf unlimited setzen. Also verkraften sollte der Server das schon (2x Dual-Core-Opteron, 4GB Speicher, 4 SCSI-HDD im Raid 5 (Hardware) Modus). Ich dachte, dass er abstürzt. Allerdings wenn man über ps -A alle laufenden Programme anzeigen lässt, steht hinter lockd zumindest nicht <defunct>.
Was mich übrigens wundert: ich hatte vorher opensuse 10.2 laufen, da sind nie Fehler aufgetreten. Das Limit für open files war da auch schon auf 1024 gesetzt und die Anzahl der Clients war gleich. Im übrigen tritt der Fehler schon auf, wenn schnell (1 min) hintereinander ca. 10 - 15 Rechner anmelde.
Lars Ziegler wrote:
Lars Ziegler schrieb:
Sandy Drobic schrieb:
open files lässt sich allerdings nicht auf unlimited setzen. Also verkraften sollte der Server das schon (2x Dual-Core-Opteron, 4GB Speicher, 4 SCSI-HDD im Raid 5 (Hardware) Modus). Ich dachte, dass er abstürzt. Allerdings wenn man über ps -A alle laufenden Programme anzeigen lässt, steht hinter lockd zumindest nicht <defunct>.
Was mich übrigens wundert: ich hatte vorher opensuse 10.2 laufen, da sind nie Fehler aufgetreten. Das Limit für open files war da auch schon auf 1024 gesetzt und die Anzahl der Clients war gleich. Im übrigen tritt der Fehler schon auf, wenn schnell (1 min) hintereinander ca. 10 - 15 Rechner anmelde.
Dann vermute ich schon fast, dass wir auf einer falschen Fährte sind. Ist das der kernel-NFS oder der userland NFS? Ich meine, dass es dort einige Unterschiede gab, die Probleme verursachen konnten.
Sandy Drobic schrieb:
Lars Ziegler wrote:
Lars Ziegler schrieb:
Sandy Drobic schrieb:
open files lässt sich allerdings nicht auf unlimited setzen. Also verkraften sollte der Server das schon (2x Dual-Core-Opteron, 4GB Speicher, 4 SCSI-HDD im Raid 5 (Hardware) Modus). Ich dachte, dass er abstürzt. Allerdings wenn man über ps -A alle laufenden Programme anzeigen lässt, steht hinter lockd zumindest nicht <defunct>.
Was mich übrigens wundert: ich hatte vorher opensuse 10.2 laufen, da sind nie Fehler aufgetreten. Das Limit für open files war da auch schon auf 1024 gesetzt und die Anzahl der Clients war gleich. Im übrigen tritt der Fehler schon auf, wenn schnell (1 min) hintereinander ca. 10 - 15 Rechner anmelde.
Dann vermute ich schon fast, dass wir auf einer falschen Fährte sind. Ist das der kernel-NFS oder der userland NFS? Ich meine, dass es dort einige Unterschiede gab, die Probleme verursachen konnten.
Es läuft der kernel-NFS. Hab auch schon verschiedene kernel ausprobiert. Hat nichts geholfen.
Lars Ziegler wrote:
Sandy Drobic schrieb:
Lars Ziegler wrote:
Lars Ziegler schrieb:
Sandy Drobic schrieb: open files lässt sich allerdings nicht auf unlimited setzen. Also verkraften sollte der Server das schon (2x Dual-Core-Opteron, 4GB Speicher, 4 SCSI-HDD im Raid 5 (Hardware) Modus). Ich dachte, dass er abstürzt. Allerdings wenn man über ps -A alle laufenden Programme anzeigen lässt, steht hinter lockd zumindest nicht <defunct>.
Was mich übrigens wundert: ich hatte vorher opensuse 10.2 laufen, da sind nie Fehler aufgetreten. Das Limit für open files war da auch schon auf 1024 gesetzt und die Anzahl der Clients war gleich. Im übrigen tritt der Fehler schon auf, wenn schnell (1 min) hintereinander ca. 10 - 15 Rechner anmelde.
Dann vermute ich schon fast, dass wir auf einer falschen Fährte sind. Ist das der kernel-NFS oder der userland NFS? Ich meine, dass es dort einige Unterschiede gab, die Probleme verursachen konnten.
Es läuft der kernel-NFS. Hab auch schon verschiedene kernel ausprobiert. Hat nichts geholfen.
Ich habe trotzdem den finsteren Verdacht, dass etwas mit dem Kernel nicht stimmt. Wie sieht es eigentlich mit den Anwendungen aus, nutzen diese alle den gleichen Locking-Mechanismus?
Sandy Drobic schrieb:
Lars Ziegler wrote:
Sandy Drobic schrieb:
Lars Ziegler wrote:
Lars Ziegler schrieb:
Sandy Drobic schrieb: open files lässt sich allerdings nicht auf unlimited setzen. Also verkraften sollte der Server das schon (2x Dual-Core-Opteron, 4GB Speicher, 4 SCSI-HDD im Raid 5 (Hardware) Modus). Ich dachte, dass er abstürzt. Allerdings wenn man über ps -A alle laufenden Programme anzeigen lässt, steht hinter lockd zumindest nicht <defunct>.
Was mich übrigens wundert: ich hatte vorher opensuse 10.2 laufen, da sind nie Fehler aufgetreten. Das Limit für open files war da auch schon auf 1024 gesetzt und die Anzahl der Clients war gleich. Im übrigen tritt der Fehler schon auf, wenn schnell (1 min) hintereinander ca. 10 - 15 Rechner anmelde.
Dann vermute ich schon fast, dass wir auf einer falschen Fährte sind. Ist das der kernel-NFS oder der userland NFS? Ich meine, dass es dort einige Unterschiede gab, die Probleme verursachen konnten.
Es läuft der kernel-NFS. Hab auch schon verschiedene kernel ausprobiert. Hat nichts geholfen.
Ich habe trotzdem den finsteren Verdacht, dass etwas mit dem Kernel nicht stimmt. 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?
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?
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. :-/
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.
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.
Also ich hab jetzt mal deine letzten Tipps ausprobiert und in die Datei /etc/security/limits.conf folgenden Eintrag vorgenommen:
* soft nofiles 4096
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.
Vielen Dank übrigens für deine Geduld und Hilfe :-)
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.
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 4096Sorry, mein Fehler, ohne das "s":
soft nofile 4096Ein 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.
Lars Ziegler wrote:
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.
Sehr schön. Was wieder einmal zeigt, dass Symptom und Ursache häufig nicht das gleiche sind (lockd auf dem Server und Firewall-Einstellungen auf dem Client).
Das ist übrigens häufig ein Test, den ich mache: Firewall deaktivieren und testen, ob die Kommunikation dann plötzlich funktioniert.
Sandy Drobic schrieb:
Lars Ziegler wrote:
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.
Sehr schön. Was wieder einmal zeigt, dass Symptom und Ursache häufig nicht das gleiche sind (lockd auf dem Server und Firewall-Einstellungen auf dem Client).
Das ist übrigens häufig ein Test, den ich mache: Firewall deaktivieren und testen, ob die Kommunikation dann plötzlich funktioniert.
Das hatte ich auch, aber halt leider nur am Server :-)
-
Lars Ziegler -
Sandy Drobic