Problem bei Arbeit auf externer Festplatte (bootable image)

Hallo allerseits,

in der Hoffnung, die vorhandenen Forumsbeiträge hinreichend gründlich durchsucht zu haben, möchte ich nun folgendes Problem beschreiben:

Variante (1):
Das Betriebssystem wird von einem "bootable image" (externe Festplatte) geladen, anschließend Thunderbird gestartet

Variante (2)
Die externe Festplatte ("bootable image") wird mit dem von der internen Festplatte gebooteten Rechner verbunden und Thunderbird mit einer entsprechenden Einstellung (Extras/Konten/Lokale Ordner/Speicherplatz) dazu gebracht, die Mail-Daten von der externen Festplatte ("Spiegel)" zu lesen.

In beiden Fällen startet Thunderbird erfolgreich, verhält sich dann aber merkwürdig:
- der Inhalt einer Mail zu einem angeklickten "Betreff" wird mit großer Verzögerung oder gar nicht angezeigt
- Thunderbird läßt sich nicht mehr schließen; nur noch "sofort beenden" (kill -9)
- nach erneutem Start wird auch nach langem Warten (20 min) kein Mail-Inhalt mehr angezeigt.
- kaum disk-I/O (!)
- Folder-Struktur ist immer korrekt wiedergegeben...

Das ganze unter/mit:
- MacOS 10.4.11, Powerbook G4 (PowerPC)
- Thunderbird 2.0.0.14
- externe Platte mit FireWire400 verbunden
- image mit "Festplattendienstprogramm" generiert
- viele Mails, viele Folder (3,4 GB [sic]) -- arbeitet sonst ganz wunderbar, bei jahrelanger, täglicher Nutzung! Aber vielleicht ist das Datenvolumen doch der Schuldige...

Anmerkungen:
(Variante 1) Das Problem klingt vielleicht exotisch, ist aber doch nicht so fernliegend, da es mir schon (im Ausland) passiert ist, daß die interne Festplatte hing. In einem solchen Fall wäre es schön, zumindest übergangsweise von der externen Platte booten und "leben" zu können...
(Variante 2) Zugriff auf "clone"/"backup"/"mirror" - wäre auch nicht schlecht.

Habe keine Zweifel, daß eine mit dem Image "wiederhergestellte" interne Disk keine Probleme machen wird...

Versuche noch, aus den kernel traces (MacOS "ktrace" output) schlau zu werden...

Herzlichen Dank für jeden sachdienlichen Hinweis!

ises.

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.