CPU-Auslastung mit Dropbear 0.49/Busybox 1.4.1

[bodega]

Hallo,

ich hab den dropbear jetzt nicht installiert, es würde mich aber interessieren ob der CPU-Hog auch auftritt, wenn der Dienst verzögert gestartet wird (z.B. in der /var/flash/debug.cfg mit einem sleep 30 davor). Und ob er auftritt, wenn man das sleep 30 weg lässt.

 

[kriegaex]

Ja. Ich habe den Dienst per Init-Skript gestoppt und neu hochgefahren und es dann nochmal probiert. Hätte mich auch gewundert, wenn das einen Unterschied gemacht hätte.

Edit: Die Ursache ist ja ungefähr bekannt. Der Busybox-Entwickler, welcher sich darum kümmert, ist nur momentan ein bis zwei Wochen unterwegs und kommt nicht gleich dazu, einen Fix zu produzieren.

 

[kriegaex]

Der Fehler sollte mit ds26-14.4 behoben sein. Bitte alle mal testen und dann ggf. diesen u.ä. Threads auf "erledigt" setzen.

 

[schmatke]

Also bei mir siehts gut aus. Kann man Hindergründe erfahren?

 

[kriegaex]

Warum und wieso

Ja, kannst Du. Der "Patch" ist sehr umfangreich - ein Zeichen (ein "x" weniger).

--- shell/ash.c.ori     2007-01-24 22:34:40.000000000 +0100
+++ shell/ash.c 2007-04-29 15:40:44.000000000 +0200
@@ -6560,7 +6560,9 @@
                /* turning job control off */
                fd = ttyfd;
                pgrp = initialpgrp;
-               xtcsetpgrp(fd, pgrp);
+               /* was xtcsetpgrp, but this can make exiting ash
+                * with pty already deleted loop forever */
+               tcsetpgrp(fd, pgrp);
                setpgid(0, pgrp);
                setsignal(SIGTSTP);
                setsignal(SIGTTOU);

Die Shell muß die zum Zeitpunkt ihres Aufrufs im Vordergrund laufende Prozeßgruppe während ihrer Laufzeit in den Hintergrund befördern. Wenn die Shell terminiert, muß das rückgängig gemacht werden, die Prozeßgruppe muß zurück in der Vordergrund. Das geht auf C-Ebene mittels

• tcsetpgrp(ctty_fd, process_group_id) oder
• xtcsetpgrp(ctty_fd, process_group_id)

Die Variante mit dem "x" unterscheidet sich von der einfacheren dadurch, daß sie im Fehlerfall eine Meldung aufs kontrollierende Terminal (tty) schreibt. In unserem Fall (Client gekillt) ist das Tty aber nicht mehr da, was die Shell in Verwirrung stürzt und zu einer Endlosschleife führt, während der immer wieder versucht wird, die Fehlermeldung erneut auszugeben. Wir mußten der Shell entweder beibringen, diesen Fall zu ignorieren oder vermeiden, daß sie versucht, aufs Tty zu schreiben. Für Letzteres hat sich der Busybox-Programmierer dann entschieden.

Alles Klarheiten beseitigt?

 

[schmatke]

Danke für die schnelle Antwort!
Vor allem der zweite Teil war sehr erleuchtend! :idea:

Das Problem war schon sehr lästig. Von diversen Orten bekomme ich einfach keine dauerhafte Verbindung hin (mit OpenVPN auch nicht). Und da war es schon nervend, mich immer wieder neu zu verbinden und den Prozess zu beenden.
Aber das Problem scheint ja der Vergangenheit anzugehören.

 

[jesus.christ]

Kann auch für meine 7150 bestätigen, dass der Bug nicht mehr auftritt. Vielen Dank für die Arbeit
Gruß Niko

 

[TriaxMan]

gibt es irgendwo die neue "BusyBox 1.5.x " und "dropbear 0.49" zum downloaden? (nicht für ds-mod)

 

[kriegaex]

Bau sie Dir mit dem DS-Mod, Du kannst sie dann ja manuell nachladen, mußt den Mod nicht installieren. Aber es wäre schon sinnvoller, die vorhandene BB zu ersetzen, denn sonst hast Du ja zwei drauf.

Abgesehen davon, bist Du off-topic. Bitte keine weiteren Fragen hierzu in diesem Thread.

Edit: Nachdem ich per PN beschimpft und gefragt wurde, weshalb das wohl OT sei, möchte ich hier nochmal nach persönlicher ausführlicher Beantwortung der Frage öffentlich und sachlich in Kurzform die Begründung nachliefern:

• Wir befinden uns im DS-Mod-Unterforum und der Schreiber gibt selbst an, den DS-Mod nicht zu verwenden.
• Es geht um ein (längst gelöstes) Problem bzgl. hoher Systemauslastung im Zusammenhang mit Dropbear, der Schreiber hat dieses Problem aber gar nicht oder gibt dies zumindest nicht an, sondern fragt lediglich nach vorkompilierten Binaries.

Ergo: doppelt OT. Ich hoffe, das genügt als Begründung.

 

[cuma]

Sorry dass ich diesen alten Thread aufwärme. Hab gerade bemerkt dass meine 7170 immer sehr heiss ist und mir mal die CPU Last angeschaut. Budybox ist der Auslöser mit dem hier beschriebenen Problem! Ist es nicht sinnvoll den Patch in aktuelle ds-mod Releases einzubinden?

 

[kriegaex]

Beschreibe Deinen Fehler bitte genauer und leg ein paar Logs von ps und top bei. Beschreibe bitte auch, wie Du den Fehler reproduzierst und hänge evtl. noch Deine .config an. Grund: Der Fehler sollte seit 14.4 draußen sein.

P.S.: Und von welchem Patch sprichst Du?

 

[cuma]

Der Patch mit "xtcsetpgrp" in diesm thread von dir vom 29.04.2007, 20:48. Wie gefunden? Ich hab einfach in den Sourcecode reingeschaut! Problem ist halt das ohne "exit" ssh 99% CPU-Last hat. Mir ist auch vorher schon aufgefallen dass die Weboberflächen "zäh" sind
Ich hab den Patch jetzt manuell reingemacht und es läuft problemlos.

Die .config häng ich später an, hab die jetzt nicht hier. Hab aber nur ein paar Pakete (<10) , ext3 und ftdi drinnen.

 

[schmatke]

Welchen dsmod verwendest Du? Das Problem ist doch alt! Und bestand bis ds26-14.4.

"neuestes ds26" kann doch fast nicht sein. ??? Oder???

 

[cuma]

So, hab mein Signatur mal mit meiner ganzen Config komplettiert. Wie jetzt dort zu sehen benutze ich ds26-15.2.
Dass das Problem schon lange behoben ein sollte hab ich bemerkt. Ist bei mir aber trotzdem aufgetreten. Zum kompilieren entpacke ich immer das dsmod frisch in ein neues Verzeichnis. Zum compilieren benutz ich Fedora Core 6

 

[kriegaex]

So, jetzt weiß ich - Ihr dürft mich Sherlock nennen - was los ist:

• Ich hatte mit BusyBox 1.4.1 und ds26-14.4 den Patch mit aufgenommen, damit war das Problem behoben.
• Im BusyBox-Repository wurde er als Rev. #18530 ebenfalls eingecheckt, und zwar in der Hauptlinie (trunk).
• Unglücklicherweise wurde er weder nach 1.4.1 noch 1.4.2 oder 1.5.x übernommen, denn der Entwicklungszweig (Branch) für 1.5.x war damals schon angelegt. Leider hat sich, obwohl das Release noch nicht raus war, keiner im BusyBox-Team darum gekümmert, den Bugfix zu mergen.
• Oliver hatte nicht damit gerechnet und den Patch mit unserem zwischenzeitlichen Wechsel zu BusyBox 1.4.2 in unserer internen Rev. #288 wieder heraus genommen (zusammen mit fünf anderen Patches, die auch wirklich weg mußten) und damit den Fehler quasi reaktiviert, was erst mal keinem aufgefallen ist.
• Es gibt zwar inzwischen BusyBox 1.6.1, in welcher der Fehler gefixt ist, wir sind aktuell aber noch auf BB 1.5.1, brauchen den Patch also folglich noch, was ich aber durch den "Hinweis" von cuma (stand in seiner Signatur und warf Fragen auf) eben erst aufgrund o.g. Nachforschungen bemerkte. Danke Dir, und nächstes Mal bitte deutlich den Fehler melden, nicht einfach still und leise selbst patchen.

Was also ist zu tun bis zum Release ds26-15.3? Patch wieder einspielen. Ich hänge ihn hier nochmals an und werde aus dem Release-Thread auf diesen Beitrag verweisen.

Vorgehensweise:

# 1. Patch herunterladen und ins DS-Mod-Basisverzeichnis kopieren
# 2. Patch entpacken
tar xvjf bb151_ash_endless_loop_patch.tar.bz2

 

[cuma]

Hallo,
kann das nicht ganz so stehen lassen. Hab doch gestern Abend/heut Früh in diesem Thread geschrieben

Budybox ist der Auslöser mit dem hier beschriebenen Problem! Ist es nicht sinnvoll den Patch in aktuelle ds-mod Releases einzubinden?

und

Problem ist halt das ohne "exit" ssh 99% CPU-Last hat.

und

Dass das Problem schon lange behoben ein sollte hab ich bemerkt. Ist bei mir aber trotzdem aufgetreten.

Hab ja erst seit einer Woche die 7170 und ds-mod. Wenn ich einen Fehler finde will ich nicht gleich ein riesen Aufsehen veranstalten, ohne dass diesen Fehler jemand bestätigt hat. Vielleicht habe ich ja auch irgend etwas falsch gemacht.

Ich gelobe aber Besserung

PS @kriegaex:Diesen FTDI-Patch evtl auch noch ins nächste Release aufnehmen!?

 

[m.kress]

Hi,
welche Datei muß ich denn touchen, damit bei einer bereits ohne Patch kompilierten Busybox der make diese inkl. Patch erneut kompiliert?

 

[RalfFriedl]

Das einfachste ist, das Verzeichnis source/ref-8mb_26/busybox-1.5.1/ zu löschen, entweder mit make busybox-dirclean oder von Hand.

 

[udosw]

# 1. Patch herunterladen und ins DS-Mod-Basisverzeichnis kopieren
# 2. Patch entpacken
tar xvjf bb151_ash_endless_loop_patch.tar.bz2

Ich muss das Thema leider nochmal aufwärmen. Ich habe ds_mod 15.2 gepatcht, d.h. wie oben vorgegangen und vor dem make ein make busybox_dirclean durchgeführt.

Jetzt zeigen sich merkwürdige Effekte:

Ich rufe z.B. 'which' auf

/ $ which
BusyBox v1.5.1 (2007-08-30 08:32:00 CEST) multi-call binary

Usage: which [COMMAND ...]

Locate a COMMAND

und habe anschließend zwei weitere (gestorbene?) which-Prozesse in meiner Tasklist (die oberen 4 sund von 2 vorherigen Aufrufen):

 / $ ps
[...]
 1822 root            Z   [which]
 1823 root            Z   [which]
 1826 root            Z   [which]
 1827 root            Z   [which]
 1830 root            Z   [chmod]
 1831 root            Z   [chmod]
 1837 root       1432 S   /bin/sh /mod/sbin/joe cfg_mc 
 1839 root        688 R   /mod/sbin/joe.bin cfg_mc 
 1845 root            Z   [which]
 1846 root            Z   [which]
 1847 root       1432 R   ps

Wenn ich ein Terminal-Fenster mit einer Shell schließe, entsteht zwar keine hohe CPU-Last, aber wenn ich eine Anwendung, z.B. Editor (w3c - bei mir in joe umbenannt) auf habe, und dann das Fenster schließe, passiert das:

(top)
Mem: 29012K used, 1320K free, 0K shrd, 2008K buff, 6676K cached
Load average: 2.01 1.48 0.73
  PID USER     STATUS   VSZ  PPID %CPU %MEM COMMAND
 1839 root     R        688  1837 93.4  2.2 joe.bin
 1848 root     R       1436  1772  3.4  4.7 top
  436 root     S       3932     1  2.4 12.9 multid
 1097 root     S      21256  1088  0.1 70.0 asterisk
  482 root     S       1440     1  0.1  4.7 busybox
 1110 root     S      21256  1088  0.0 70.0 asterisk
 1109 root     S      21256  1088  0.0 70.0 asterisk
[...]

Dasselbe Problem, wenn ich die CLI vom Asterisk laufen habe und dann das Terminal schließe.

Edit: Nachtrag: Nach 2 mal DSL-Reconnet über das Web-Interface von ds_mod sieht es so aus:

 2131 root            Z   [sh]
 2136 root            Z   [dsld]
 2137 root            Z   [dsld]
 2141 root            Z N [kdsld_token]
 2143 root            Z   [sh]
 2218 root            Z   [sh]
 2223 root            Z   [dsld]
 2224 root       4504 S   dsld 
 2228 root            RWN [kdsld_token]
 2230 root            Z   [sh]
 2293 root       1432 R   ps

:noidea:
Udo

 

[kriegaex]

In anderem Zusammenhang gibt es mit den aktuellen Firmwares wegen eines AVM-Bugs bei UPnP Zombie-Prozesse. Da könnte das Entfernen der UPnP-Bestandteile im Mod helfen. Ist aber nur eine Vermutung, vielleicht liegt es auch an Asterisk (nie getestet, also ein bequemer Verdächtiger) oder einem anderen ungewöhnlichen Konfigurationsdetail. Ich habe hier jedenfall keinerlei Probleme dieser Art.