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