Hohe CPU-Last beim Schließen des Terminal-Fensters

[udosw]

Bitte mal diesen Thread angucken. Wenn Asterisk läuft und ich ein Terminal-Fenster schließe, steigt die CPU-Load extrem an. Ich hatte gehofft, dass es mit dem Patch der Busybox vorbei ist, ist aber nicht so.

Am schlimmsten ist es, wenn ich z.B. auf der Asterisk-CLI bin und das Fenster schließe. Die Idee der Antwort #43 könnte zwar für * selber zutreffen, aber für ein Fenster mit der CLI kann das ja nicht zutreffen.

Kann es an der Busybox liegen, die mit * selber mitkommt? Das ist ja eine 1.4er. Wird * aus dieser BB heraus gestartet? Hat die evtl. diesen Fehler?

Udo

 

[RalfFriedl]

Die Antwort in #43 bezog sich auf die Zombie Prozesse, nicht auf die CPU Auslastung.

Die hohe CPU Auslastung kommt dann, wenn noch ein Programm läuft (oder mehrere), die Verbindung getrennt wird und das Programm nicht damit zurecht kommt, daß das Terminal plötzlich weg ist.

Die einfachste Lösung dafür ist, daß man das nicht macht.

Die andere Frage ist, was soll passieren, wenn man zum Beispiel die Asterisk CLI offen hat und die Verbindung beendet?
Soll Asterisk dann auch beendet werden?
Soll Asterisk dann in den Hintergrund gehen?

Du kannst versuchen, strace für die Box zu erstellen und damit festzustellen, was Asterisk in dieser Situation macht, wenn es die hohe CPU Auslastung verursacht.

 

[udosw]

Die Antwort in #43 bezog sich auf die Zombie Prozesse, nicht auf die CPU Auslastung.

Schon richtig, mir schienen aber die Symptome gleich zu sein: Programm wird nicht richtig beendet.

Die einfachste Lösung dafür ist, daß man das nicht macht.

Das meinst Du jetzt nicht im Ernst ...:-Ö Also ehrlich, in der täglichen Arbeit finde ich es ganz normal, dass das mal passiert.

...CLI offen hat und die Verbindung beendet?

Nichts!

Soll Asterisk dann auch beendet werden?

Natürlich nicht!

Soll Asterisk dann in den Hintergrund gehen?

Der Asterisk ist doch im Hintergrund. Die CLI ist quasi eine Remote-Verbindung dorthin.

Anders gesagt: Auf jedem Linux-Sytem, auf dem ich bisher gearbeite habe, war es kein Problem, in einer CLI oder auch wenn mal ein Editor offen ist o.ä. die Verbindung einfach zu beenden. Der entsprechende Prozess beendet sich einfach - wo ist das Problem? Beim Editor gibt's eben ein DEAD-File.

strace ist auf der FritzBox nicht vorhanden. k.A. ob's das gibt.

Udo

 

[RalfFriedl]

Meiner Meinung nach sind CPU-Auslastung und Zombies zwei verschiedene Probleme.

Ein Zombie ist ein Prozeß, der beendet ist, dessen Parent sich aber noch nicht den Exit Status abgeholt hat. Ein Zombie Prozeß verbraucht keine CPU Zeit, nur etwas Speicher.
Der Parent Prozeß von im Hintergrund gestarteten Prozessen ist init, wenn der sich nicht um die beendeten Prozesse kümmern kann, liegt es vermutlich daran, daß die Datei /etc/init.d/rc.S bzw. die von dieser gestartete debug.cfg nicht beendet wurde.

Wenn ein Prozeß viel CPU Zeit verbraucht, ist er nicht beendet, sondern läuft noch, und zwar so übermäßig, daß das Probleme verursacht.

Ich habe nicht gesagt, daß es die eleganteste Lösung ist, das Problem zu vermeiden, nur die einfachste.

Mit Asterisk CLI meinst Du anscheinend "asterisk -r" und nicht "asterisk -c".
Dann kann natürlich der Server nicht beendet werden, weil er ja gar nicht mit dem Terminal verbunden ist. Aber vom "asterisk -r" erwartest Du, daß er beendet wird, ohne soviel CPU Zeit zu verbrauchen.

Ein strace für die Box kannst Du Dir mit dem ds-mod erstellen. Du muß dafür den ds-mod nicht installieren, es reicht, wenn Du das Programm auf die Box bringst.

Ich vermute, daß das Problem aus zwei Teilen besteht.
- Dropbear signalisiert vermutlich das Ende einer Verbindung nicht so wie andere Programme dies tun.
- Andere Programme wie die Shell oder in diesem Fall Asterisk reagieren nicht gut darauf, wenn ihre Verbindung zum Terminal einfach weg ist. Die Shell zum Beispiel hat immer versucht, von der Eingabe zu lesen, einen Fehler bekommen, und dann das Ganze von vorne. Damit hat sie dann die gesamte verfügbare CPU-Kapazität damit verbraucht. Wahrscheinlich macht Asterisk das Gleiche.

Die Frage ist jetzt, ob man Dropbear oder Asterisk ändern soll.

 

[olistudent]

Sollte der 160-tty_close.patch für dropbear das nicht lösen?

MfG Oliver

 

[udosw]

Hmm, ich verwende dropbear gar nicht, sondern gehe per telnet auf die Box. Werde dropbear aber mal testen jetzt.

@RalfFriedel: Die Diskussion CPU-Auslastung <-> Zombies können wir mal einstellen, das ist geklärt. Und: Natürlich geht es um 'asterisk -r', '-c' geht ja nicht, da der * auf der Box läuft. Siehe meine Signatur.

Gruß
Udo

 

[RalfFriedl]

Ich dachte Du gehst mit Dropbear auf die Box, weil es im anderen Thread um CPU-Auslastung mit Dropbear ging.
Du könntest durchaus auf der Box "asterisk -c" aufrufen, auch wenn das eher für Testzwecke sinnvoll ist als für den echten Einsatz.
Das "asterisk -r" rufst Du aber auch auf der Box auf, oder?
Ich weiß es jetzt nicht mehr genau, aber telnet und dropbear unterscheiden sich in ihrem Verhalten, wenn die Verbindung beendet wird, oder waren zumindest mal unterschiedlich. Kann sein, daß der angesprochene Patch das geändert hat.
Wobei eine hohe CPU-Last von einem Programm, dessen Terminal-Verbindung weg ist, in jedem Fall nicht gut ist.

 

[udosw]

Das Problem tritt auch auf, wenn ich über dropbear (ssh) auf die Box gehe.

Udo

 

[olistudent]

Ich muss jetzt nochmal fragen:
Den letzten FAQ-Punkt von hier hast du beachtet und die busybox danach auch neu gebaut?
Was wird mit der busybox vom * gemacht?

MfG Oliver

 

[udosw]

busybox danach auch neu gebaut?

Ja (siehe mein erstes posting). Wobei ich mich frage, wie man eigentlich nachträglich prüfen kann, ob der Patch wirklich durchgeführt wurde.

Was wird mit der busybox vom * gemacht?

Keine Ahnung, ich hab nicht genau verstanden, wieso * so gebaut ist (läuft in einer chroot-Umgebung).

Das Problem tritt aber nicht nur mit * auf: Wenn ich z.B. mit nvi eine Datei bearbeite und das Terminal beende ist es genauso.

Udo

 

[olistudent]

Das kannst du nur nachprüfen indem du unter ds26-15.2/source/ref-xmb/busybox-1.5.1 usw. nachschaust.

MfG Oliver

 

[udosw]

Also, ich hab das nochmal genau durchgecheckt: Der Patch ist drin. Das Problem nesteht weiter.

Udo