CPU-Auslastung mit Dropbear 0.49/Busybox 1.4.1

[jesus.christ]

Hi all,
was mir heute zufällig aufgefallen ist, nachdem Dropbear 0.49/Busybox 1.4.1 auf meiner Box läuft: wenn die Putty-Session nicht per "exit" geschlossen, sondern einfach nur das Fenster geschlossen wird, dann sehe ich im Top den Prozess "sh" mit einer CPU-Auslastung von nahezu 100%, wenn ich eine neue Putty-Session starte.

Hat das was mit einem Fehler in der Busybox zu tun? Mit der Kombination Dropbear 0.48.1/Busybox 1.3.? ist mir das nie untergekommen.

Gruß Niko

 

[olistudent]

Hi.
Mit dem Problem ärger ich mich auch schon länger rum. Aber irgendwie werd ich da draus nicht schlau.
Wenn ich mit "/etc/init.d/rc.dropbear restart" den Dienst neu starte, dann tritt das Problem nicht mehr auf.

MfG Oliver

 

[andreasz]

Die CPU-Last geht nach ein paar min zurück, habe eine Zeitlang die Busybox 1.4.1 benutzt und dieses problem oft gehabt, wenn mal wieder die verbindung über WLAN aus dem Büro abgebrochen ist

 

[olistudent]

Bei mir nicht. Es scheint ein Problem mit der busybox zu sein. Aber den Fehler zu beheben bin ich nicht in der Lage...

/var/mod/root $ ./strace -p 1813
Process 1813 attached - interrupt to quit
write(2, "\n", 1)                       = -1 EIO (Input/output error)
ioctl(10, 0x80047476, 0x7fbad9bc)       = -1 ENOTTY (Inappropriate ioctl for device)
write(2, "-sh", 3)                      = -1 EIO (Input/output error)
write(2, "Cannot set tty process group (", 30) = -1 EIO (Input/output error)
write(2, "\n", 1)                       = -1 EIO (Input/output error)
ioctl(10, 0x80047476, 0x7fbad9bc)       = -1 ENOTTY (Inappropriate ioctl for device)

Und so geht das immer weiter...

MfG Oliver

edit: So sollte es aussehen:

/var/mod/root $ ./strace -p 1914
Process 1914 attached - interrupt to quit
read(0, "", 1)                          = 0
--- SIGHUP (Hangup) @ 0 (0) ---
Process 1914 detached
/var/mod/root $

Das Problem tritt bei mir mit busybox 1.4.1 auf und mit busybox 1.3.1 nicht.

 

[kriegaex]

Kann das Phänomen bestätigen, ebenfalls Busybox 1.4.1 und Putty. Ist mir bisher nie aufgefallen, war aber sofort reproduzierbar. Der sh-Prozeß wollte durch einfachen kill nicht verschwinden, es war schon kill -kill <pid> notwendig.

 

[jesus.christ]

Mit anderen Worten, ein Downgrade auf die 1.31 ist fällig. Funktioniert das einfach, indem ich die Version in der Config-File auf 1.31 setze oder müssen noch andere Patches angepasst werden?
Gruß Niko

EDIT: Scheint wohl so, da es ein paar unresolved symbols _printk in libs gibt...

 

[kriegaex]

Ich bin gegen ein Downgrade, 1.4.1 funktioniert ansonsten gut, da ich grundsätzlich meine Sitzungen mit exit beende. Stattdessen sollten wir, was dieses Problem und auch das altbekannte (Putty beendet sich nicht, wenn die erste Telnet-Konsole geschlossen wird) betrifft, eher versuchen, den Fehler zu finden.

 

[jesus.christ]

Ich beende sie normalerweise auch immer mit exit. Das Problem ist aber, wenn der PC z.B. in den Ruhestand geht und dabei Netzwerkverbindungen getrennt werden oder die bereits erwähnte schlechte WLAN-Verbindung.
Gruß Niko

 

[kriegaex]

Ah, verstehe.

 

[olistudent]

Kann das bitte mal jemand ausprobieren?
Bei mir tritt die hohe CPU-Last nur auf, wenn der dropbear vom dsmod gestartet wird. Wenn ich den dropbear von der Kommandozeile starte, dann ist alles okay. Auch wenn ich das Fenster nicht über exit schließe.
Verstehen muss das aber keiner, oder?

MfG Oliver

 

[schmatke]

Kann ich nicht bestätigen. Ohne exit schießt sh nach oben.

 

[olistudent]

Ich habs jetzt nochmal probiert. Mit dem gleichen Ergebnis:
dropbear von der Kommandozeile gestartet:

/var/mod/root $ ./strace -p 3533
Process 3533 attached - interrupt to quit
read(0, "", 1)                          = 0
--- SIGHUP (Hangup) @ 0 (0) ---
Process 3533 detached
/var/mod/root $

dropbear aus dem dsmod-Webif gestartet:

/var/mod/root $ ./strace -p 4008
Process 4008 attached - interrupt to quit
read(0, "", 1)                          = 0
--- SIGHUP (Hangup) @ 0 (0) ---
--- SIGCONT (Continued) @ 0 (0) ---
ioctl(0, TIOCSCTTY, {B38400 opost isig icanon echo ...}) = -1 EIO (Input/output error)
rt_sigaction(SIGWINCH, {0x10000000, [], 0}, {0x10000000, [], 0x46ecd4}, 16) = 0
ioctl(10, 0x80047476, 0x7f8619bc)       = -1 ENOTTY (Inappropriate ioctl for device)
write(2, "-sh", 3)                      = -1 EIO (Input/output error)
write(2, "Cannot set tty process group (", 30) = -1 EIO (Input/output error)
write(2, "\n", 1)                       = -1 EIO (Input/output error)
ioctl(10, 0x80047476, 0x7f8619bc)       = -1 ENOTTY (Inappropriate ioctl for device)
write(2, "-sh", 3)                      = -1 EIO (Input/output error)
write(2, "Cannot set tty process group (", 30) = -1 EIO (Input/output error)
write(2, "\n", 1)                       = -1 EIO (Input/output error)
ioctl(10, 0x80047476, 0x7f8619bc)       = -1 ENOTTY (Inappropriate ioctl for device)
write(2, "-sh", 3)                      = -1 EIO (Input/output error)
write(2, "Cannot set tty process group (", 30) = -1 EIO (Input/output error)
write(2, "\n", 1)                       = -1 EIO (Input/output error)
ioctl(10, 0x80047476, 0x7f8619bc)       = -1 ENOTTY (Inappropriate ioctl for device)
write(2, "-sh", 3)                      = -1 EIO (Input/output error)
write(2, "Cannot set tty process group (", 30) = -1 EIO (Input/output error)
write(2, "\n", 1)                       = -1 EIO (Input/output error)
ioctl(10, 0x80047476, 0x7f8619bc)       = -1 ENOTTY (Inappropriate ioctl for device)...

MfG Oliver

 

[jesus.christ]

Ich checke es heute abend zu Hause.

EDIT: kann es auch nicht bestätigen. Auch von der Shell aus gestartet bleibt das Problem dasselbe.

Gruß Niko

 

[jesus.christ]

Weiß jemand, ob sich in der Busybox 1.5 bezüglich der Problematik etwas geändert hat?
Gruß Niko

 

[kriegaex]

Danke, Andreas. Bin auch gespannt, ob jemand damit Erfolg hat. Ich flashe zurzeit ungern, da ich das von unterwegs zwar könnte, aber nicht im Notfall den Stecker ziehen kann.

Davon abgesehen, daß das vielleicht die Lösung sein könnte, wüßte ich gern die Begründung. Selbst wenn es helfen sollte, checke ich ungern was ein, das ich nicht verstehe. Hat der Kollege mit gdb debuggt? Hat er den Patch aus der Busybox-Mailingliste? Also bitte Quelle und Begründung nachreichen. Nicht, daß dadurch dann etwas anderes nicht mehr geht.

 

[andreasz]

Habs erstmal entfernt, da ich das momentan selber noch nicht nachstellen kann, muß ihn mal fragen, wo er die Einträge gefunden hat. Hatte ihm nur kurz die FM gemailt und auf die Busybox Seite verwiesen, sollte ihm mal die 1.4.1 Sourcen zukommen lassen, damit er dort nochmals durchsieht. Ne begründung hatte er mir geliefert, aber nur kurz mündlich und das auch noch beim Rauchen ohne PC in der nähe. Werde mich am Dienstag mit ihm zusammen setzten und nochmal schauen, bzw ihm ne erklärung dafür entlocken.

 

[andreasz]

Weiß jemand, ob sich in der Busybox 1.5 bezüglich der Problematik etwas geändert hat?
Gruß Niko

Habs mit der 1.5.0 versucht, keine änderung

 

[kriegaex]

Aussicht auf Problembehebung

Es gibt neue Infos zur Problemursache und Aussicht auf Problembehebung, siehe dort.

 

[TriaxMan]

Habs mit der 1.5.0 versucht, keine änderung

hast du zufällig auch ein statisches binary von der 1.5.0 busybox?

 

[rannseier]

Den Fehler hab ich auch mit der Busybox 1.0 auf einem Allnet 6200 und den OpenWRTs.