JerryWho

Ich hatte doch seiner Zeit versucht, den Apache dazu zu bewegen, Coredumps zu schreiben. Nun weiß ich, was man neben den ulimit Einstellungen vornehmen muss:
Man muss noch durch die Directive CoreDumpDirectory das Verzeichnis angeben, in das der Dump gehen soll.

Um das Netzwerkkarten-Problem mit dem PE 2850 unter SLES 9 zu lösen, empfahl Dell ja, das neueste Service Pack von SuSE einzuspielen. Dies hatte ich erfolgreich getan. Alles lief auf dem Rechner, bis jetzt traten die Netzwerkkarten-Probleme nicht wieder auf.
Aber: Plötzlich traten beim Apache 1.3 auf ganz bestimmten php-Seiten Abstürze auf. Im error_log fanden sich Einträge der Art
child pid ddddd exit signal Segmentation fault (11)
Diese Fehler waren immerhin reproduzierbar. Zunächst dachte ich, dass bei den Updates eine Library, gegen die der Apache, PHP oder mod_perl gelinkt waren, ausgetauscht wurden und nun die Probleme verursachen. Als aber eine neue Kompilierung dieser drei Bausteine nichts brachte, war guter Rat teuer.
Ich versuchte dann, den Apache dazu zu bewegen, einen Coredump in ein core file zu schreiben. Ich habe also zunächt per ulimit -c unlimited für root die maximale Größenbeschränkung aufgehoben. Der Apache weigerte sich aber nach wie vor, sein core file zu schreiben. Daraufhin habe ich den Prozess als normaler Nutzer ohne uid-Wechsel laufen lassen (an einem Port >1024 natürlich) und für diesen Nutzer das Limit aufgehoben. Wieder ohne Erfolg. (Wenn mir jemand sagen kann, wie zu dem core file komme, würde ich mich freuen.)
Also Griff ich dann zum gdb. Zunächst startete ich den Apache mit der Option -X, um ihn im Vordergrund laufen zu lassen. Per gdb -p konnektierte ich mich an den Prozess (später versuchte ich es auch per run -X -f httpd.conf innerhalb es gdb mit dem gleichen Effekt). Ich rief die Fehler-produzierende Seite auf und erhielt die Meldung
Cannot find user-level thread for LWP ddddd: capability not available
Wie ich mich drehte und wendete, ich kam nicht an die Fehler.produzierende Library…
Plötzlich kam mir die Idee, dass LWP Light Weight Process, also Threads heißen könnte. Da fiel mir ein, dass ich doch gerade was im SAP-Hinweis 171356 darüber gelesen hatte und dass man über die Umgebungsvariable LD_ASSUME_KERNEL=2.4.1 auf die alte Variante zurückschalten kann. Gesagt, getan, und der Apache lief wieder ohne Fehler.

Ich habe nun den Kernel  2.6.5-7.244 eingespielt, der nun das Problem beheben soll. Mal schauen, was sich so tut….

Nun habe ich also wie von Dell und Novell/SuSE empfohlen auf den neuesten Kernel aktualisiert. Leider tritt das Problem nun häufiger auf als früher …
Wenn ich tippen müsste, was ich nun tun soll, so würde ich sagen, dass ich nun das BIOS aktualisieren muss. Dies dürfte sicherlich nochmal ein Kapitel heikler sein.
Vielleicht sollte ich die internen Karten vergessen und eine gewöhnliche Feld- Wald- und Wiesennetzwerkkarte einbauen.

Das beschriebene Problem scheint Novel/SuSE wohl wirklich mit dem Abschalten des TSO per ethtool zu lösen, wenn man diesen Beitrag hier beachtet. Mein Problem ist (toi toi toi) seit dem anscheinend gelöst.

Ein typischer Fall von "denkste". Ich dachte, das Abschalten von TSO würde das Problem lösen. Doch dem war leider nicht so. Nach zwei Wochen Ruhe trat das Problem wieder auf….

Dell hat sich nun mit SuSE in Verbindung gesetzt und folgenden Lösungsvorschlag unterbreitet:
ethtool -K tso off /dev/eth0
Ich habe daraufhin mal ein wenig gegoogelt und bin zum Thema tso auf eine Seite bei Dell
gestoßen, die sich u.a. mit TCP Segmentation Offload (TSO) befasst. Mal schauen, ob es mein Problem löst

Die schwierigsten Probleme bei der Fehlerbehebung sind ja bekanntlich die "Blinker-Effekte": Geht, geht nicht, geht, geht nicht.
Mit einem solchen Problem kämpfe ich zur Zeit bei einem Dell PowerEdge 2850.
Dieser Rechner wird unter dem SuSE Enterprise Server 9 (SLES 9) betrieben. Gelegentlich, aber natürlich immer zur unpassenden Zeit ist dieser Rechner nicht per Netzwerk zu erreichen. Die Zeitspanne ist gerade so lange, dass meine Nagios
-Überwachung anschlägt. Bis man aber reagieren kann, sprich bis man im Server-Raum angekommen ist, läuft schon wieder alles bestens.
In /var/log/messages findet man die beiden folgenden Einträge:
NETDEV WATCHDOG: eth0: transmit timed out
kernel: e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex
Googlet man nach dieser Fehlermeldung, so findet man häufig den Hinweis, dass man das ACPI ausschalten soll. Dies habe ich zähneknirschend getan (schließlich ist danach auch das Hyperthreading weg….) — allerdings ohne Erfolg. Sucht man weiter, findet man bei DELL den Hinweis (allerdings für Red Hat Linux), man solle auf jeden Fall beim Netzwerkkarten-Treiber den Parameter RxIntDelay auf "0" setzen. Dies brachte leider auch nicht den gewünschten Effekt.
Die üblichen Verdächtigen sind auch schon ausgeschlossen worden: Das Netzwerkkabel und der Port im Switch wurden getauscht. Auch die zweite interne Netzwerkkarte wurde ausprobiert. Ebenso wurden sowohl Switch als auch die Netzwerkkarte fest auf 100MBit und Full-Duplex gestellt.
Nun stochert der Support von Dell im Nebel und hat das ganze an SuSE eskaliert. Die wollen aber nun weitere Reports — nach Möglichkeite unmittelbar nach dem Auftreten des Fehlers — haben.
So warte ich darauf, dass der Fehler sich wieder zeigt….