Bernd Brodesser wrote:
Hallo Liste,
ich stand mal wieder kurz vor einem Absturz.
Nicht unbedingt, ob hängt davon ab, was genau passiert ist. Die von Dir beschriebenen Symptome deuten auf einen Memory-Race hin, d.h. etwas, dass entweder mehr Speicher allozieren wollte, wie verfügbar, oder auf etwas, dass rekursiv unendlich viel Speicher allozieren wollte. Dieses etwas kann ein Programm sein (dann wäre es ein Bug im Programm), der Kernel (d.h. ein Memory Leak im Kernel) oder auch einer Bibliothek (d.h. ein Bug in einer Library, zB. der Speicherverwaltung in der libc).
Puh, gerade noch gerettet. Daher mal ein paar Fragen dazu. Vielleicht weiß ja jemand eine Antwort.
Erstmal, top sah folgendermaßen aus:
Mem: 127624K av, 34976K used, 92648K free, 2256K shrd, 1768K buff Swap: 666776K av, 17240K used, 649536K free 17004K cached
Warum wird da Swap benutzt, obwohl genügend Mem frei ist? Weil irgendetwas in den virtuellen Speicher geladen wurde, aber im Augenblick gerade nicht benutzt wird.
Dies tritt bei Memory-Races gerne auf, da der gerade aktive (durchgedrehte) Prozess dann allen verfügbaren Speicher allozieren will und andere Dinge (z.B. dein gerade offener Netscape oder irgendwelche schlafenden Daemons) geswappt werden. Hat sich das System danach dann wieder gefangen, bleiben diese dann bis sie wieder benutzt werden, ausgelagert. Wenn das System danach weiterläuft und der Swap auch irgendwann mal wieder freigegeben wird ist wahrscheinlich alles in Ordnung. Allerdings können Memory-Races auch durch Kernel-Bugs hervorgerufen werden.
Warum ist überhaupt soviel frei?
Das war allerdings nachdem das System extrem langsam wurde. Passt genau. Dieses "Langsam werden" war der Memory-Race, der alle anderen Prozesse in den Swap gedrängt hat, bevor seine Speicheranforderungen zur Folge hatten, dass diese nur noch im Swap erfüllt werden konnten (680 MB Swap bei 128MB RAM ist nicht unbedingt sinnvoll).
Vorher war kein Swap mehr frei. Nichts, niente. Oftmals kommt es dann zum Absturz. Eigenartigerweise funktionieren die Terminalumschaltung ALT+FX auch noch nach einem Totalabsturz, nicht aber die Umschaltung von X auf einem Terminal. Überhaupt ist an einem Absturz immer X beteiligt.
Ist da mit dem neuen Kernel oder mit dem neuen XFree Besserung in Sicht? Um dazu eine Aussage machen zu können sind deine Angaben nicht aussagekräftig genug.
Es wäre wichtig zu wissen, welches Programm durchging. Ein Top während des Memory-Races würde Auskunft geben können. Ansonsten passen die Symptome auf * die berüchtigten Memory-Leaks in Kerneln < linux-2.2.16-SuSE bzw. linux-2.2.17. * die Memory-Leaks in der glibc2 * Treiberbugs. * Den klogd Bug in älteren Kernels * Einen Bug in g++-2.95.2 * Das End-Of-RAM Problem Und solltest Du 2.4.x-Kernels oder KDE2 einsetzen, ... no comment.
ALT+SysRq ist ja ganz nett, aber damit kann man auch nur den Rechner neu booten. Ich suche was um den XServer killen zu können, auch wenn alles steht.
Moment mal, wieso alles steht? Wenn Dich oben richtig verstanden habe, lief dein System hinterher doch noch, nur konntest während der Swapperei nicht interaktiv eingreifen, oder? Ansonsten: als Root auf der Konsole: killall -9 X Ralf --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com