Für's Protokoll, weil nicht uninteressant:
"ktrace" von Thunderbird "in trouble" liefert die vielsagende(n) Zeile(n):
(...)
297 thunderbird-bin RET open -1 errno 24 Too many open files
(...)
Und tatsächlich, im Terminal-Fenster überprüft:
localhost:~ root# ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) 6144
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 256 <---- !!!
pipe size (512 bytes, -p) 1
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 100
virtual memory (kbytes, -v) unlimited
localhost:~ root#
Die Prozesshierarchie des Terminals bzw. von Thunderbird:
launchd (uid: root) -> WindowServer (uid: windowserver) -> thunderbird-bin (uid: meine)
launchd (uid: root) -> WindowServer (uid: windowserver) -> Terminal (uid: meine)
Der mögliche Maximalwert von "open files":
root # sysctl -a | grep maxfiles
kern.maxfiles = 12288 <--- !!!
kern.maxfilesperproc = 10240
root #
Also lautete die Aufgabe, den schockierend kleinen Wert "256" für die Maximalzahl offener Dateien für den WindowServer zu erhöhen - denn ein "parent" gibt die Limits an seine "childs" weiter (wenn diese jene nicht nocheinmal ändern...)
Zur Sicherheit aber ersteinmal die Richtigkeit der Annahme prüfen, indem Thunderbird aus einem Terminal-Fenster
mit geeigneten Limits gestartet wird:
localhost:~ isessler$ ulimit -n unlimited
localhost:~ isessler$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) 6144
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 12288 <---- !!!
pipe size (512 bytes, -p) 1
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 100
virtual memory (kbytes, -v) unlimited
localhost:~ isessler$
localhost:~ isessler$ /Applications/http://Thunderbird.app/Contents/MacOS/thunderbird-bin
localhost:~ isessler$
alles o.k.!!! :-))
Die einzige Lösung, die Limits für den WindowServer zu ändern, fand ich im Schreiben eines "wrappers":
(1) Gehe in das Verzeichnis, in dem der WindowServer "zuhause" ist:
root # cd /System/Library/Frameworks/ApplicationServices.framework/Frameworks/CoreGraphics.framework/Resources
(2) Benenne den WindowServer um:
root # mv WindowServer WindowServer.orig
(3) Erstelle den "wrapper" (Script) mit dem Namen "WindowServer":
root # cat WindowServer
#!/bin/zsh
ulimit -n unlimited
/System/Library/Frameworks/ApplicationServices.framework/Frameworks/CoreGraphics.framework/Resources/WindowServer.orig $*
root #
(4) Passe permissions an:
root # chmod 755 WindowServer
root # ls -l WindowServer*
-rwxr-xr-x 1 root wheel 153 May 25 14:14 WindowServer
-rwxr-xr-x 1 root wheel 14208 Mar 10 2006 WindowServer_orig
root #
Reboot - und weitere Tests: alles o.k.!!!
Vielleicht kennt ja jemand eine elegantere Lösung? Ein "richtiges" UNIX läßt das ja zu...
ises.