CPU-Auslastung mit Dropbear 0.49/Busybox 1.4.1

@udosw: Ich kann das Problem nicht nachtvollziehen. Es liegt wohl an den von dir benutzten Programmen. Ich habe folgendes versucht:
Code:
which;which;which;which;which;which;which;which;which;which;which;which;      ps|grep which;echo RUN AFTER SLEEP:;sleep 1;ps |grep which;
und die Ausgabe
Code:
[...]
Usage: which [COMMAND ...]

Locate a COMMAND

 3172 root            Z   [which]
 3173 root            Z   [which]
 3175 root            Z   [which]
 3176 root            Z   [which]
 3178 root            Z   [which]
 3179 root            Z   [which]
 3181 root            Z   [which]
 3182 root            Z   [which]
 3184 root       1868 R   which
 3185 root            Z   [which]
 3187 root       1428 S   grep which
RUN AFTER SLEEP:
 3190 root       1428 S   grep which
$


Ist also alles ok!
 
cuma schrieb:
Es liegt wohl an den von dir benutzten Programmen.

Ich habe aber eben rausgefunden, dass ein Neustart des Asterisk die Zombie-Prozesse verschwinden lässt. Ein laufender e3c aus einem geschlossenen Fenster bleibt aber erhalten. Ich werde die Frage im Asterisk on FBF-Forum stellen.

Udo
 
Das Problem ist vermutlich, daß asterisk aus debug.cfg so gestartet wird, daß die debug.cfg nicht beendet wird. Beim Beenden von asterisk wird dann die debug.cfg beendet und dann läuft init normal weiter.

Es gab hier schon von kurzem eine Diskussion über Zombie Prozesse, da war der Effekt ähnlich, wenn auch das gestartete Programm ein anderes war. Dort stehen weitere Einzelheiten dazu.
 
Guter Hinweis, das könnte tatsächlich sein. Ein kleines kaufmännisches Und an der richtigen Stelle wirkt da manchmal Wunder. ;-)
 
Also ich habe am Ende von rc.custom (natürlich! Danke kriegaex) und debug.cfg ein
Code:
eventadd 1 "Running $0 $* done."
und sehe so schön über Syslog wann die Startprozesse abgearbeitet sind
 
Zuletzt bearbeitet:
Die Aussagekraft ist aber begrenzt, wenn aus debug.cfg oder rc.custom (das meinst Du wohl) heraus asynchrone Hintergrundprozesse gestartet werden, aber das ist ja klar. Ich erwähne es nur der Vollständigkeit halber.
 
Busybox Patch einspielen geht nicht.

Hallo zusammen,

das Einspielen des Patches funktioniert bei mir nicht. Habe vor dem Kompilieren auf ds26-15.2 den Patch: bb151_ash_endless_loop_patch.tar.bz2 wie beschrieben eingespielt. Trotzdem habe ich die hohe CPU Auslastung der Shell wenn ich die SSH Session nicht mit exit beende.

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


Kann mir jemand sagen was ich falsch mache?
Mache es wie beschrieben Patch runtergeladen -> ins Basisverzeichnis kopiert -> entpackt mit tar xvjf bb151_ash_endless_loop_patch.tar.bz2 . Oder muss ich vorher:
bunzip2 bb151_ash_endless_loop_patch.tar.bz2 ausführen. Und dann:
patch -p0 < 150-ash_endless_loop.patch ausführen.

Bin für jeden Tip dankbar! Denn ansonsten läuft bei mir alles!!!!!

Gruß, Spiderman
 
Nach # 2. Patch entpacken musst du den Patch anwenden (patch -p0 < 150-ash_endless_loop.patch). Welcher Output kommt da?
Dann nochmal "make busybox-dirclean; make".

MfG Oliver
 
folgende FM bekomme ich, wenn ich patch -p0 < 150-ash_endless_loop.patch anwende

Gruß, spiderman

Code:
drwxr-xr-x 3 root root 4,0K 2008-04-08 18:16 .
drwxr-xr-x 4 root root 4,0K 2008-04-08 18:13 ..
-rw-r--r-- 1 root root 4,1K 2008-04-08 18:13 100-busybox-getcons.patch
-rw-r--r-- 1 root root  279 2008-04-08 18:13 110-busybox-nolock-as-default.patch
-rw-r--r-- 1 root root  931 2008-04-08 18:13 120-busybox-shadow-path.patch
-rw-r--r-- 1 root root  169 2008-04-08 18:13 130-trylink_bash.patch
-rw-r--r-- 1 root root  825 2008-04-08 18:13 140-wget-base64enc.patch
-rw-r--r-- 1 1001 1001  392 2007-08-13 18:12 150-ash_endless_loop.patch
-rw-r--r-- 1 root root  364 2008-04-08 18:13 200-fix_setconsole.patch
-rw-r--r-- 1 root root  28K 2008-04-08 18:13 300-httpd.patch
-rw-r--r-- 1 root root 5,0K 2008-04-08 18:13 300-stty_option_parsing.patch
-rw-r--r-- 1 root root  790 2008-04-08 18:13 310-httpd_env.patch
-rw-r--r-- 1 root root  920 2008-04-08 18:13 330-httpd_user_agent.patch.broken
-rw-r--r-- 1 root root  446 2008-04-08 18:13 400-awk_segfault.patch
-rw-r--r-- 1 root root  971 2008-04-08 18:13 410-httpd_cgi_headers.patch.broken
-rw-r--r-- 1 root root  776 2008-04-08 18:13 440-httpd_chdir.patch.broken
-rw-r--r-- 1 root root 1,4K 2008-04-08 18:13 450-help_text.patch
-rw-r--r-- 1 root root 2,1K 2008-04-08 18:13 busybox-1.4.1-inetd_mem.patch
drwxr-xr-x 6 root root 4,0K 2008-04-08 18:13 .svn
StinkyLinux:/home/avm/ds26-15.2/make/busybox/patches# patch -p0 < 150-ash_endless_loop.patch
can't find file to patch at input line 3
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|--- shell/ash.c        2007/04/14 10:09:57     18436
|+++ shell/ash.c        2007/04/28 22:39:02     18530
--------------------------
File to patch:
 
Wenn micht nicht alles täuscht, muss der Patch im Verzeichnis source/busybox-host/busybox-1.4.1/ angewendet werden.
 
Der Patch muss nach make/busybox/patches kopiert werden...

MfG Oliver
 
Der Patch wurde automatisch mit: tar xvjf bb151_ash_endless_loop_patch.tar.bz2
ins Verzeichnis: "make/busybox/patches" kopiert. Trotzdem bekomme ich die o.g. FM. :-(

wenn ich dann erneut den Filenamen hinter File to patch: eingebe, bekomme ich diese FM:

Code:
slightly@StinkyLinux:~/avm/ds26-15.2/make/busybox/patches$ patch -p0 < 150-ash_endless_loop.patch
can't find file to patch at input line 3
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|--- shell/ash.c        2007/04/14 10:09:57     18436
|+++ shell/ash.c        2007/04/28 22:39:02     18530
--------------------------
[b]File to patch: 150-ash_endless_loop.patch[/b]
patching file 150-ash_endless_loop.patch
Hunk #1 FAILED at 3500.
1 out of 1 hunk FAILED -- saving rejects to file 150-ash_endless_loop.patch.rej
slightly@StinkyLinux:~/avm/ds26-15.2/make/busybox/patches$

anschließend sehe ich im Verzeichnis make/busybox/patches zusätzlich diese Dateien
Code:
-rw-r--r-- 1 slightly slightly  392 2008-04-09 07:02 150-ash_endless_loop.patch.orig
-rw-r--r-- 1 slightly slightly  494 2008-04-09 07:06 150-ash_endless_loop.patch.rej

könnte das irgendein Rechte Problem sein?
 
Oliver schrieb, dass du diesen PAtch kopieren sollst, und nciht direkt anwenden. Die Patches in diesem Unterverzeichnis werden vor dem Kompilieren automatsich angewendet.

Vergiss vorher nicht ein make busybox-dirclean zu machen.
 
Juhu!!!! es läuft!!!!!! Vielen Dank für Eure Unterstützung Jungs!!!
Ich habe den Fehler gefunden. Es war scheinbar ein Rechte Problem. Ich kompiliere unter Stinky Linux. Das Image hatte ich nicht unterhalb vom slightly ordner kompiliert, sondern ich habe einen neuen Ordner 'avm' unter /home zum kompilieren erstellt.

Die Anleitung von Kriegaex funktioniert einwandfrei!

Gruß, spiderman.
 
Dein "Rechteproblen" ist kein Problem, sondern ein feature eines Betriebsystems. Das home-Verzeivchnis wurde deshalb gewählt /(und dafür gibt es sdie auch), um eben nciht jedem Benutzer Zugriff auf jede Stelle des Systems zu gewähren. Vor allem aber keinen schreibenden.

Da dies aber anscheinend für die meistne zu kompliziert ist, ist ein Unterordner in "slightly"'s home-verzeichnis wohl die allereinfachste wahl, die man machen kann.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.