Speicherverwaltung und Absturz
Hallo Liste, ich stand mal wieder kurz vor einem Absturz. 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? Warum ist überhaupt soviel frei? Das war allerdings nachdem das System extrem langsam wurde. 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? 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. Bernd -- Umsteiger von Microsoft Windows xx? Hast Du schon file://usr/doc/howto/de/DE-DOS-nach-Linux-HOWTO.txt gelesen? Auch file://usr/doc/Books/Linuxhandbuch.dvi ist zu empfehlen. |Zufallssignatur 1 --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
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
Hallo Ralf, Danke für Deine schnelle Antwort. * Ralf Corsepius schrieb am 25.Okt.2000:
Bernd Brodesser wrote:
ich stand mal wieder kurz vor einem Absturz. Nicht unbedingt, ob hängt davon ab, was genau passiert ist.
Klar. Deshalb auch fast.
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).
Wenn wir mal Hardwareprobleme außen vor lassen, dann bin ich der Meinung, daß der Kernel es im Griff kriegen müßte, egal wie kaput ein Programm ist. Wenn ein kaputes Programm mehr Speicher anfordert als es gibt, dann müßte der Kernel Stopp sagen.
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.
Ja.
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.
Schon klar. Aber das System stand doch deshalb still, weil ständig geswapt wurde, nehme ich mal an.
Wenn das System danach weiterläuft und der Swap auch irgendwann mal wieder freigegeben wird ist wahrscheinlich alles in Ordnung.
Ja. Wenn er freigegeben wird.
Allerdings können Memory-Races auch durch Kernel-Bugs hervorgerufen werden.
Hmm, klar, wenn ein Kernel nicht richtig funktioniert, kann man alles vergessen.
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).
Warum ist das nicht 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.
Schön, und wie rufe ich top auf, wenn nichts mehr geht? Ich kann ja noch nicht mal zur Konsole wechseln. Und auf X kann ich auch nichts machen. Ich weiß, da gibt es ähnliche Teile.
Ansonsten passen die Symptome auf * die berüchtigten Memory-Leaks in Kerneln < linux-2.2.16-SuSE bzw. linux-2.2.17.
linux-2.2.14 Original SuSE 6.4
* 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.
Nein, ich setze keinen 2.4er Kernel ein. Ja, ich setze KDE2 ein. Na und? Es kann doch nicht angehen, daß ein wie auch immer kaputes Anwenderprogramm ein System zum Absturz bringt. Das ist doch der Riesenvorteil von einem UNIX, daß da immer noch der Kernel sitzt und das Anwenderprogramm nicht alles erlaubt. Auch nicht wenn es von root ist, was im übrigen bei mir nicht der Fall war.
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?
Ja. Ich habe jetzt nicht vom aktuellen Fall geredet. Sorry, ging ein wenig durcheinander. Aber so was habe ich schon mal von Zeit zu Zeit. Allerdings sehr selten. Waren bestimmt andere Kernel. Experimentelle Kernel benutze ich allerdings nicht. Wenn ich auch sonst gerne ein wenig rumexperimentiere, aber am Kernel lieber nicht.
Ansonsten: als Root auf der Konsole: killall -9 X
Ach und wie komme ich auf der Konsole? Nein auch eine Eingabe auf einem xterm funktioniert dann nicht mehr. Und wenn ich auf einer Konsole bin, dann nimmt sie aber nichts mehr an. Im aktuellen Fall habe ich auch so was ähnliches gemacht. Ich habe einfach auf der Konsole auf der ich startx aufgerufen habe ein CTRL-C eingegeben. Geht imho am schnellsten. Nur leider ist deswegen eine Konsole belgt, wenn ich startx nicht im Hintergrund schicke. Bernd -- Was ist quoten? Quoten ist das Zitieren aus einer mail, der man antwortet. Und wie macht man es richtig? Zitate werden mit "> " gekennzeichnet. Nicht mehr als nötig zitieren. Vor den Abschnitten das Zitat, auf das man sich bezieht, mit einer Zeile Abstand oben und unten. |Zufallssignatur 12 --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Bernd Brodesser wrote:
* Ralf Corsepius schrieb am 25.Okt.2000:
Bernd Brodesser wrote:
ich stand mal wieder kurz vor einem Absturz. Nicht unbedingt, ob hängt davon ab, was genau passiert ist.
Klar. Deshalb auch fast.
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).
Wenn wir mal Hardwareprobleme außen vor lassen, Auch das wäre natürlich eine Möglichkeit. Wenn Du aber nichts an deiner HW-Konfiguration geändert hast, eher unwahrscheinlich.
dann bin ich der Meinung, daß der Kernel es im Griff kriegen müßte, egal wie kaput ein Programm ist. Wenn ein kaputes Programm mehr Speicher anfordert als es gibt, dann müßte der Kernel Stopp sagen. Tut er normalerweise auch, doch in der Zwischenzeit dauert es halt den Swap zu füllen :)
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.
Schon klar. Aber das System stand doch deshalb still, weil ständig geswapt wurde, nehme ich mal an.
Nicht unbedingt. Bei Races ausserhalb des Kernels wird das System oft interaktiv kaum noch bedienbar, was dann den Eindruck erweckt, als ob das System stillstände. Bei Races im Kernel habe ich allerdings auch schon erlebt, dass gar keine Eingaben mehr akzeptiert wurden (reiserfs auf SuSE-6.3/SMP #:-), mit SuSE-7.0 scheint es jetzt einigermassen stabil :)
Wenn das System danach weiterläuft und der Swap auch irgendwann mal wieder freigegeben wird ist wahrscheinlich alles in Ordnung.
Ja. Wenn er freigegeben wird.
Probier mal nach einem derartigen Vorfall einen swapoff -a. Stürzt das System danach richtig ab, ...
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).
Warum ist das nicht sinnvoll?
Darüber kann man vortrefflich streiten (Hatten wir auf dieser Liste schon öfters :). Zu Zeiten als RAM selten war (<32/64MB) galt mal die Faustregel Swap = 2-3x RAM, doch heutzutage ist das etwas fragwürdig, da das Füllen von mehreren Hundert MB Swap einfach sehr viel Zeit braucht (u.U. mehrere 10 Minuten) und das System währenddessen kaum noch nutzbar ist. Braucht man derartig grosse Mengen Swap gelegentlich auch wirklich, ist jedoch nichts gegen grosse Mengen Swap einzuwenden - man sollte sich nur im klaren darüber sein, dass es einige Zeit braucht den Swap zu füllen. Wird dann noch während des Swappens interaktiv weitergearbeitet, werden u.U. Hunderte MB vom Swap mehrfach ins RAM und wieder zurückgeschaufelt. Bei 128MB RAM reichen 128 MB Swap meiner bescheidenen Meinung nach vollkommen aus. Wenn nicht - dann mehr RAM.
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.
Schön, und wie rufe ich top auf, wenn nichts mehr geht? Ich kann ja noch nicht mal zur Konsole wechseln. Und auf X kann ich auch nichts machen. Ich weiß, da gibt es ähnliche Teile. Siehe unten - alternativ und falls Du das Problem einigermassen reproduzieren kannst, lass einen top parallel mitlaufen.
Ansonsten passen die Symptome auf * die berüchtigten Memory-Leaks in Kerneln < linux-2.2.16-SuSE bzw. linux-2.2.17.
linux-2.2.14 Original SuSE 6.4
OK, das wäre ein ganz heisser Kandidat. Alle Kernels vor den oben genannten Versionen hatten Memory-Leaks, die nur sporatisch und auch nicht in allen Konfigurationen auftraten, von denen die Kernelentwickler (bzw. SuSE) glauben sie nun weitgehend gefixt zu haben.
* die Memory-Leaks in der glibc2 * Treiberbugs. * Den klogd Bug in älteren Kernels
Der klogd Daemon in älteren Kernels ging manchmal durch, allokierte den gesamten virtuellen Speicher und starb danach, meist ohne das System weiter zu beeinträchtigen. Ob der 2.2.14-SuSE Kernel auch diese Problem hatte, kann ich mich leider nicht mehr errinnern. Wenn top während eines Races hohe Load durch klogd anzeigt, vorher klogd aktiv war und hinterher fehlt oder sich in einen Zombie gewandelt hat, dürfte es sich mit hoher Wahrscheinlichkeit um dieses Problem handeln. Auch hier hilft ein Kernelupdate.
* Einen Bug in g++-2.95.2 * Das End-Of-RAM Problem
Ich meinte das alte Problem mit mem=(physikaler Speicher - einige MB). Wenn der Kernel dann doch mal auf das Ende des physikalen Speichers zugreift, geht's dahin, fängt sich manchmal aber auch wieder - Die Symptome können dann so aussehen wie von Dir beschrieben.
Und solltest Du 2.4.x-Kernels oder KDE2 einsetzen, ... no comment.
Nein, ich setze keinen 2.4er Kernel ein. Ja, ich setze KDE2 ein. Na und? Es kann doch nicht angehen, daß ein wie auch immer kaputes Anwenderprogramm ein System zum Absturz bringt. Das ist doch der Riesenvorteil von einem UNIX, daß da immer noch der Kernel sitzt und das Anwenderprogramm nicht alles erlaubt. Auch nicht wenn es von root ist, was im übrigen bei mir nicht der Fall war.
Alles richtig, nur ist KDE2 so neu, dass die Wahrscheinlichkeit auf einen Race in Libraries oder Applikationen zu treffen sehr hoch ist, ich KDE2 also als sehr wahrscheinliche Fehlerquelle ansehen würde.
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?
Ja. Ich habe jetzt nicht vom aktuellen Fall geredet. Sorry, ging ein wenig durcheinander. Aber so was habe ich schon mal von Zeit zu Zeit. Allerdings sehr selten. Waren bestimmt andere Kernel. Experimentelle Kernel benutze ich allerdings nicht. Wenn ich auch sonst gerne ein wenig rumexperimentiere, aber am Kernel lieber nicht.
Ansonsten: als Root auf der Konsole: killall -9 X
Ach und wie komme ich auf der Konsole? Tja, das ist ein Problem :-)
Meist ist es so, das während Races kaum Eingabeevents (Tastatur/Maus) mehr zum Zuge kommen, meist aber doch, d.h. liegt der Keyboardfocus während eines Races zufällig auf einem Terminal kann blindes Eintippen von killall -9 X helfen oder auch Wechseln auf die Konsole gelingen. Eine meist funktionierende Alternative besteht darin, von einer anderen Maschine aus auf der betroffenen Maschine eingeloggt zu sein und von dort aus einen killall -9 X abzusetzen zu versuchen. Ralf --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
On 25-Oct-2000 Ralf Corsepius wrote:
Meist ist es so, das während Races kaum Eingabeevents (Tastatur/Maus) mehr zum Zuge kommen, meist aber doch, d.h. liegt der Keyboardfocus während eines Races zufällig auf einem Terminal kann blindes Eintippen von killall -9 X helfen oder auch Wechseln auf die Konsole gelingen. Eine meist funktionierende Alternative besteht darin, von einer anderen Maschine aus auf der betroffenen Maschine eingeloggt zu sein und von dort aus einen killall -9 X abzusetzen zu versuchen.
Was macht man aber, wenn man einen Stand-alone-Rechner hat?
ALT+SysRq empfinde ich nicht als so gute Alternative. Vor kurzem
habe ich mir nun einen Joystick gekauft. Eigentlich wollte ich erst
einmal selbst etwas experimentieren, aber da dieses Problem gerade
angeschnitten wurde, will ich doch mal schon fragen, ob jemand
schon Erfahrung damit hat, killall -9 X per Joystick auszufuehren.
Ist natuerlich nur ein Kurieren von Symptomen, aber besser als der
Returnknopf.
Gruss,
Heinz.
--
E-Mail: Heinz W. Pahlke
Hallo Ralf, * Ralf Corsepius schrieb am 25.Okt.2000:
Bernd Brodesser wrote:
* Ralf Corsepius schrieb am 25.Okt.2000:
Bernd Brodesser wrote:
Wenn wir mal Hardwareprobleme außen vor lassen,
Auch das wäre natürlich eine Möglichkeit. Wenn Du aber nichts an deiner HW-Konfiguration geändert hast, eher unwahrscheinlich.
Ja.
dann bin ich der Meinung, daß der Kernel es im Griff kriegen müßte, egal wie kaput ein Programm ist. Wenn ein kaputes Programm mehr Speicher anfordert als es gibt, dann müßte der Kernel Stopp sagen.
Tut er normalerweise auch, doch in der Zwischenzeit dauert es halt den Swap zu füllen :)
Ich habe schon mal ein Wochenende lang gewartet. Tat sich nichts. Länger kann ich nicht warten. ;)
Schon klar. Aber das System stand doch deshalb still, weil ständig geswapt wurde, nehme ich mal an.
Nicht unbedingt. Bei Races ausserhalb des Kernels wird das System oft interaktiv kaum noch bedienbar, was dann den Eindruck erweckt, als ob das System stillstände. Bei Races im Kernel habe ich allerdings auch schon erlebt, dass gar keine Eingaben mehr akzeptiert wurden (reiserfs auf SuSE-6.3/SMP #:-), mit SuSE-7.0 scheint es jetzt einigermassen stabil :)
Ich habe SuSE-6.4
Wenn das System danach weiterläuft und der Swap auch irgendwann mal wieder freigegeben wird ist wahrscheinlich alles in Ordnung.
Ja. Wenn er freigegeben wird.
Probier mal nach einem derartigen Vorfall einen swapoff -a. Stürzt das System danach richtig ab, ...
Werde ich mal versuchen.
erfüllt werden konnten (680 MB Swap bei 128MB RAM ist nicht unbedingt sinnvoll).
Warum ist das nicht sinnvoll?
Darüber kann man vortrefflich streiten (Hatten wir auf dieser Liste schon öfters :).
[...]
Bei 128MB RAM reichen 128 MB Swap meiner bescheidenen Meinung nach vollkommen aus. Wenn nicht - dann mehr RAM.
Ok, werde mal was weniger swap einstellen.
Schön, und wie rufe ich top auf, wenn nichts mehr geht? Ich kann ja noch nicht mal zur Konsole wechseln. Und auf X kann ich auch nichts machen. Ich weiß, da gibt es ähnliche Teile.
Siehe unten - alternativ und falls Du das Problem einigermassen reproduzieren kannst, lass einen top parallel mitlaufen.
Ja, habe ich auch schon mal gemacht.
Ansonsten passen die Symptome auf * die berüchtigten Memory-Leaks in Kerneln < linux-2.2.16-SuSE bzw. linux-2.2.17.
linux-2.2.14 Original SuSE 6.4
OK, das wäre ein ganz heisser Kandidat. Alle Kernels vor den oben genannten Versionen hatten Memory-Leaks, die nur sporatisch und auch nicht in allen Konfigurationen auftraten, von denen die Kernelentwickler (bzw. SuSE) glauben sie nun weitgehend gefixt zu haben.
Ok, werde mal einen neuen Kernel ziehen und kompelieren.
* die Memory-Leaks in der glibc2 * Treiberbugs. * Den klogd Bug in älteren Kernels
Der klogd Daemon in älteren Kernels ging manchmal durch, allokierte den gesamten virtuellen Speicher und starb danach, meist ohne das System weiter zu beeinträchtigen. Ob der 2.2.14-SuSE Kernel auch diese Problem hatte, kann ich mich leider nicht mehr errinnern. Wenn top während eines Races hohe Load durch klogd anzeigt, vorher klogd aktiv war und hinterher fehlt oder sich in einen Zombie gewandelt hat, dürfte es sich mit hoher Wahrscheinlichkeit um dieses Problem handeln.
Ja, manchmal habe ich auch etliche Zombies. Und als Parent haben die dann auch noch init. Leider ist dann init Tod.
Und solltest Du 2.4.x-Kernels oder KDE2 einsetzen, ... no comment.
Nein, ich setze keinen 2.4er Kernel ein. Ja, ich setze KDE2 ein. Na und? Es kann doch nicht angehen, daß ein wie auch immer kaputes Anwenderprogramm ein System zum Absturz bringt. Das ist doch der Riesenvorteil von einem UNIX, daß da immer noch der Kernel sitzt und das Anwenderprogramm nicht alles erlaubt. Auch nicht wenn es von root ist, was im übrigen bei mir nicht der Fall war.
Alles richtig, nur ist KDE2 so neu, dass die Wahrscheinlichkeit auf einen Race in Libraries oder Applikationen zu treffen sehr hoch ist, ich KDE2 also als sehr wahrscheinliche Fehlerquelle ansehen würde.
Ich tippe ja auch auf KDE2. Aber das kann es doch eigentlich nicht sein. Wenn ich eine Maschiene habe auf der Hinz und Kunz sich einloggen dürfen, muß ich doch damit rechnen, daß sie sogar böswillig Programme schreiben um das System zum Absturz zu bringen. Nein, ein solches System habe ich nicht. Aber da sollte doch auch Linux laufen können.
Ansonsten: als Root auf der Konsole: killall -9 X
Ach und wie komme ich auf der Konsole?
Tja, das ist ein Problem :-)
Meist ist es so, das während Races kaum Eingabeevents (Tastatur/Maus) mehr zum Zuge kommen, meist aber doch, d.h. liegt der Keyboardfocus während eines Races zufällig auf einem Terminal kann blindes Eintippen von killall -9 X helfen oder auch Wechseln auf die Konsole gelingen.
Wenn ich auf der Konsole bin geht Konsolewechsel eigenartigerweise immer noch. Das geht sogar, wenn das System runtergefahren ist und sonst gar nichts mehr geht. Aber killall eingeben geht nicht mehr, bringt auch nichts.
Eine meist funktionierende Alternative besteht darin, von einer anderen Maschine aus auf der betroffenen Maschine eingeloggt zu sein und von dort aus einen killall -9 X abzusetzen zu versuchen.
Ich habe leider nur eine Standalonemaschiene. Bernd -- ACK = ACKnowledge = Zustimmung | NAC = No ACknowledge = keine Zustimmung DAU = Dümmster Anzunehmender User | LOL = Laughing Out Loud = Lautes Lachen IIRC = If I Remember Correctly = Falls ich mich richtig erinnere OT = Off Topic = Am Thema (der Liste) vorbei |Zufallssignatur 11 --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Ralf Corsepius schrieb in 3,4K (96 Zeilen):
Und solltest Du 2.4.x-Kernels oder KDE2 einsetzen, ... no comment.
Ach, der OOM-killer (Out Of Memory-Killer) in 2.4.0-test10+ soll ganz nett werden. Extra fuer sowas. :-) -Wolfgang --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
participants (4)
-
B.Brodesser＠online-club.de -
corsepiu＠faw.uni-ulm.de -
h.pahlke＠berlin.de -
weissel＠netcologne.de