Möglicher Bug im Zusammenhang mit init von Busybox 1.16.x

[Gaucho316]

Ich habe mir am Donnerstag den RC8 des 2.4er JtG-Images geflasht. Dabei habe ich das in folgendem Thread beschrieben Problem festgestellt:
http://www.jackthegrabber.de/viewtopic.php?f=7&t=12084
Inzwischen bin ich zu dem Schluss gekommen, dass aus irgend einem Grund die profile.local ständig ausgeführt wird. Das ist doch nicht normal, oder?

Edit: Ich hab jetzt mal "top" aufgerufen. In der Liste sehe ich ständig einen Prozess "sh <defunct>" mit wechselnden PIDs. Es sieht aus, als ob ständig eine neue Shell aufgemacht wird, die wiederum ständig die Datei "profile" einliest, die dann "profile.local" einliest. Was soll das und woher kommt das? Hat da jemand einen Verdacht?

Edit: Manchmal tauchen zwischendurch statt "sh <defunct>" auch zwei Prozesse auf. Das sind "sh" und "[". Alles sehr merkwürdig.

Edit: Ich habe jetzt mal mit "ps -fA | grep defunct" geguckt, welcher Prozess als Vaterprozess angezeigt wird. Komischerweise ist es der Prozess mit der ID 1. Und das ist "init".

Edit: Könnte das Verhalten an der neuen Busybox 1.16.2 liegen?

Edit: Ich habe mal den Betreff des Threads geändert. Alter Betreff: "Möglicher Bug im Zusammenhang mit profile.local"

[dbt]

Edit: Könnte das Verhalten an der neuen Busybox 1.16.2 liegen?

Kannst du ja mal mit der Vorgängerversion testen. Da das eine wesentlicher Unterschied ist, und du Init ausgemacht hast, ist das ziemlich wahrscheinlich. ... habs ja schon mal angeschnitten, dass man 1.16.2 nicht nehmen sollte, da ist einiges irgendwie seltsam, wars mit 1.16.1 auch schon, aber in dem Fall bringt die Jagd auf die neueste Versionsnummer nicht wirklich viel, ausser viel rumpatchen.

[Gaucho316]

Ich würde erst einmal gerne wissen, ob sonst noch jemand dieses Verhalten bestätigen kann. Das mit "top" zu überprüfen, ist ja nicht schwer. Ich will nicht nach Fehlern suchen, die keine sind und sich aus irgendeinem Grund nur bei mir äußern.

[Mourice]

Hallo,

auch bei mir wird sekündlich ein "neuer" Prozess erzeugt (sh <defunct>).

Vielleicht ist das ja ein Test, um herauszufinden, wann die Prozess-Tabelle überläuft ...

Gruss

[rhabarber1848]

@Gaucho316: Poste bitte Deine /var/etc/profile.local

[Gaucho316]

An der liegt's nicht. Ich habe die schon gelöscht und dann die Box neu gestartet. Auch dann tritt das Problem mit "sh <defunct>" auf. Mourice hat den Fehler ja auch bestätigt. Ist das denn bei dir nicht so?

[rhabarber1848]

Ich nutze ein selbst kompiliertes Image mit BB 1.16.2 und automount, ohne IDE, wo der Fehler nicht auftritt.

Code: Alles auswählen

BusyBox v1.16.2 (2010-07-14 19:34:29 CEST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

~ # ps -fA | grep defunct
root      6806  6803  0 19:46 pts/0    00:00:00 grep defunct
~ # ps -fA | grep defunct
root      6808  6803  0 19:46 pts/0    00:00:00 grep defunct
~ # ps -fA | grep defunct
root      6810  6803  0 19:46 pts/0    00:00:00 grep defunct
~ # ps -fA | grep defunct
root      6812  6803  0 19:46 pts/0    00:00:00 grep defunct
~ # ps -fA | grep defunct
root      6814  6803  0 19:46 pts/0    00:00:00 grep defunct
~ # ps -fA | grep defunct
root      6816  6803  0 19:46 pts/0    00:00:00 grep defunct
~ # ps -fA | grep defunct
root      6818  6803  0 19:46 pts/0    00:00:00 grep defunct
~ # ps -fA | grep defunct
root      6820  6803  0 19:46 pts/0    00:00:00 grep defunct
~ # ps -fA | grep defunct
root      6822  6803  0 19:46 pts/0    00:00:00 grep defunct
~ # ps -fA | grep defunct
root      6824  6803  0 19:46 pts/0    00:00:00 grep defunct
~ # ps -fA | grep defunct
root      6826  6803  0 19:46 pts/0    00:00:00 grep defunct
~ # ps -fA | grep defunct
root      6828  6803  0 19:46 pts/0    00:00:00 grep defunct
~ #

[Gaucho316]

Dann frage ich mich, was im JtG-Image anders ist als bei dir und dort dieses merkwürdige Verhalten ausgelöst.

[rhabarber1848]

Nochmal ein Image neu gebaut, mit Neutrino-DriveGUI, Sambaserver

Code: Alles auswählen

IDE support:                    yes
MMC support:                    no
fdisk standalone:               yes
fstab default fs:               ext2
IDE/MMC: Ext2 support           yes / e2fsprogs
IDE/MMC: Ext3 support           no 
IDE/MMC: XFS support            no 
IDE/MMC: REISERFS support       no 
IDE/MMC: VFAT support           no 
CIFS kernel module:             yes
SMBFS kernel module:            no
LUFS kernel module:             no
NFS kernel module:              yes
NFS server:                     no
Samba server:                   no
Automount:                      yes
Neutrino UPnP-support:          no
Neutrino Audioplayer:           yes
Neutrino Movieplayer:           yes
Neutrino Pictureviewer:         no
Neutrino Mount:                 no
Neutrino Drive-Setup:           yes
Neutrino dvbsub                 no
Neutrino EPG plus               yes
Radiotext support:              yes
FLAC support:                   yes
CURL version:                   old
Freetype version:               old

um dem JTG-Image inhaltlich möglichst nahe zu kommen. Der Fehler tritt weiterhin nicht auf.
Tritt der Fehler in einem JTG-Image direkt nach dem Flashen auf?

[Mourice]

Hallo,

also ich habe mal neu geflasht.

1) neu geflasht und eben der automatische Reboot --> Problem tritt nicht auf

2) Nach dem Reboot nur "deutsch" ausgewählt, nichts anderes geändert, nichts eingespielt usw., nicht "Einstellungen speichern" gemacht

3) Dann Dbox neu gestartet über das Menü --> Problem ist da, also "sh <defunct>", wird immer wieder neu gestartet (PID wird jeweils erhöht)

Gruss

Edit: Image JTG Rc1 vom 09.05.2010, BB 1.6.1, keine Ucodes, kein Sendersuchlauf, keine Netzwerkeinstellungen

[Gaucho316]

@rhabarber1848

Vielleicht liegt's ja auch an einem der Startskripte "S*" in "/etc/init.d", die bei dir nicht ins Image gepackt werden, weil du einige Features nicht mit gebaut hast, die im JtG-Image doch drin sind. Oder werden immer alle Startskripte ins Image gepackt?

[Mourice]

@rhabarber1848

Hallo,

mir fällt nichts besseres ein, als hier mal die Prozess-Tabelle zu posten (ps -ef):

/var > ps -ef
UID PID PPID C STIME TTY TIME CMD
root 1 0 2 15:57 ? 00:00:02 init
root 2 1 0 15:57 ? 00:00:00 [keventd]
root 3 1 0 15:57 ? 00:00:00 [ksoftirqd_CPU0]
root 4 1 0 15:57 ? 00:00:00 [kswapd]
root 5 1 0 15:57 ? 00:00:00 [bdflush]
root 6 1 0 15:57 ? 00:00:00 [kupdated]
root 7 1 0 15:57 ? 00:00:00 [mtdblockd]
root 21 1 0 15:57 ? 00:00:00 [jffs2_gcd_mtd3]
root 22 1 0 15:57 ? 00:00:00 /bin/sh /etc/init.d/rcS
root 25 1 0 15:57 vc/2 00:00:00 init
root 26 1 0 15:57 vc/3 00:00:00 init
root 93 1 0 15:57 ? 00:00:00 [avia_av_wdt]
root 136 1 0 15:57 ? 00:00:00 /sbin/syslogd -O /dev/console
root 155 1 0 15:57 ? 00:00:00 inetd
1 203 1 0 15:57 ? 00:00:00 portmap
root 206 1 0 15:57 ? 00:00:00 rpc.mountd
root 208 1 0 15:57 ? 00:00:00 [nfsd]
root 209 1 0 15:57 ? 00:00:00 [nfsd]
root 210 1 0 15:57 ? 00:00:00 [nfsd]
root 211 1 0 15:57 ? 00:00:00 [lockd]
root 212 211 0 15:57 ? 00:00:00 [rpciod]
root 227 22 0 15:57 ? 00:00:00 /bin/sh /etc/init.d/start_neutrino
root 235 1 0 15:57 ? 00:00:00 sectionsd
root 236 235 0 15:57 ? 00:00:00 sectionsd
root 238 236 0 15:57 ? 00:00:00 sectionsd
root 239 236 3 15:57 ? 00:00:03 sectionsd
root 240 236 1 15:57 ? 00:00:01 sectionsd
root 241 236 0 15:57 ? 00:00:00 sectionsd
root 242 236 0 15:57 ? 00:00:00 sectionsd
root 243 236 0 15:57 ? 00:00:00 sectionsd
root 245 1 0 15:57 ? 00:00:00 timerd
root 249 245 0 15:57 ? 00:00:00 timerd
root 250 249 0 15:57 ? 00:00:00 timerd
root 254 1 1 15:57 ? 00:00:01 zapit
root 259 254 0 15:57 ? 00:00:00 zapit
root 260 259 0 15:57 ? 00:00:00 zapit
root 285 1 0 15:57 ? 00:00:00 nhttpd
root 304 227 17 15:57 ? 00:00:11 neutrino -f -u
root 313 304 0 15:58 ? 00:00:00 neutrino -f -u
root 314 313 0 15:58 ? 00:00:00 neutrino -f -u
root 321 313 0 15:58 ? 00:00:00 neutrino -f -u
root 378 155 0 15:58 ? 00:00:00 telnetd
root 379 378 3 15:58 pts/0 00:00:00 -sh
root 388 379 70 15:59 pts/0 00:00:00 ps -ef
root 389 1 0 15:59 ? 00:00:00 [sh] <defunct>

Vielleicht fällt Dir ja etwas auf, was diesen Prozess erzeugen könnte.

Ich habe nichts installiert und benutze auch "nichts". Kein nfs, kein IDE noch sonst irgend etwas.

Gruss

[Mourice]

Hallo,

habe jetzt einmal das NG-Image 2.1 getestet. Darin ist die Busybox 1.14.4.

Auch da wird sekündlich der defunct-Prozess neu gestartet.

Es ist also nicht die Busybox

Gruss

[Gaucho316]

Dann gehe ich davon aus, dass es tatsächlich an einem der neuen Init-Skripte liegt, dass im JtG-Image drin ist und in rhabarber1848s Image nicht. Ich werde nachher mal Stück für Stück ein paar Skripte deaktivieren, indem ich eine leere Datei gleichen Names mit Ausführungsrechten nach "/var/etc/init.d" lege.

Im Image sind alle Scripte drin die im CVS auch sind...

[rhabarber1848]

Oder werden immer alle Startskripte ins Image gepackt?

Nein, das ist feature-abhängig.

[Gaucho316]

Wenn ich boot.conf in /var/tuxbox/boot lösche und dann die Box neu starte, ist der Spuk vorbei. Aber, was läuft da schief?

[rhabarber1848]

Tritt das Problem in Abhängigkeit des Wertes console in boot.conf auf?
Sprich Neutrino, Einstellungen, Treiber- und Bootoptionen, Boot-Konsole.
Bei mir steht der Wert durch einen lokalen Patch

Code: Alles auswählen

--- apps/tuxbox/neutrino/src/neutrino.cpp   2009-11-10 07:26:06.000000000 +0100                                                     
+++ apps/tuxbox/neutrino/src/neutrino.cpp     2009-11-10 15:19:42.000000000 +0100                                                             
@@ -808,7 +808,7 @@                                                                                                                             
        if(fromflash)                                                                                                                           
        {                                                                                                                                       
                g_settings.uboot_baudrate       = 9600;                                                                                         
-               g_settings.uboot_console        = 0;                                                                                            
+               g_settings.uboot_console        = 1;                                                                                            
                g_settings.uboot_dbox_duplex    = 0;                                                                                            
                g_settings.uboot_lcd_inverse    = -1;                                                                                           
                g_settings.uboot_lcd_contrast   = -1;

auf seriell, der default ist Null. Vielleicht liegt es daran...

[DrStoned]

Tritt das Problem in Abhängigkeit des Wertes console in boot.conf auf?
Sprich Neutrino, Einstellungen, Treiber- und Bootoptionen, Boot-Konsole.
Bei mir steht der Wert durch einen lokalen Patch

Code: Alles auswählen

--- apps/tuxbox/neutrino/src/neutrino.cpp   2009-11-10 07:26:06.000000000 +0100                                                     
+++ apps/tuxbox/neutrino/src/neutrino.cpp     2009-11-10 15:19:42.000000000 +0100                                                             
@@ -808,7 +808,7 @@                                                                                                                             
        if(fromflash)                                                                                                                           
        {                                                                                                                                       
                g_settings.uboot_baudrate       = 9600;                                                                                         
-               g_settings.uboot_console        = 0;                                                                                            
+               g_settings.uboot_console        = 1;                                                                                            
                g_settings.uboot_dbox_duplex    = 0;                                                                                            
                g_settings.uboot_lcd_inverse    = -1;                                                                                           
                g_settings.uboot_lcd_contrast   = -1;

auf seriell, der default ist Null. Vielleicht liegt es daran...

Wäre möglich, ich verwende die RC8 des aktuellen JtG-Images, bei mir tritt das Phänomen nicht auf, da ich die Bootconsole ebenfalls auf seriell stehen habe.

Edit on: Nachdem ich die Bootconsole auf Null eingestellt habe, tritt der Fehler auch bei mir auf. Da haben wir den Übeltäter.
Edit Off:

Greetz von DrStoned

[Gaucho316]

Jetzt wäre es natürlich interessant zu wissen, warum ständig eine neue Shell geöffnet wird, wenn der Wert auf null steht. Das müsste doch ein Bug in U-Boot sein, oder?

[rhabarber1848]

habe jetzt einmal das NG-Image 2.1 getestet. Darin ist die Busybox 1.14.4.

Welche U-Boot-Version wird dort verwendet?

[Miky1968]

Welche U-Boot-Version wird dort verwendet?

Uboot: 2009.08-rc1

[Miky1968]

habe jetzt einmal das (UNERWÜNSCHTER INHALT, Anm. d. Forenbetreibers) 2.1 getestet. Darin ist die Busybox 1.14.4.

Welche U-Boot-Version wird dort verwendet?

Leute, manchmal übertreibt Ihr es aber

rhabarber 1848 hätte sicherlich keine Antwort von mir bekommen, wenn dort "(UNERWÜNSCHTER INHALT, Anm. d. Forenbetreibers)" gestanden hätte.

Vielleicht sollte mal jemand den Filter etwas zurück drehen, denn da stand ja mal NX-Return 2.1

[dbt]

Ehrlich gesagt, hätte ich nicht wirklich ein Problem damit, den Filter abzuschalten, zumindest in gewissem Umfang. Das wurde zwar schon ausgiebig vor langer Zeit diskutiert, könnte aber mal eine Auffrischung vertragen, einfach weil man die Dinge beim Namen sollte. Mit gewissen Sachen möchte man aber trotzdem lieber nicht in Verbindung gebracht werden. Diskutiert das bitte hier: http://www.tuxbox-cvs.sourceforge.net/f ... m.php?f=40

[Gaucho316]

Könnte es nicht auch am Kernel liegen? Die Parameter aus boot.conf werden doch an den Kernel übergeben, oder?

[seife]

Ich wette das ist die shell die auf der Konsole gestartet wird, aber es gibt keine Konsole, wenn "console=null". Und init probiert es halt jede sekunde neu.