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

[rhabarber1848]

Mit U-Boot 1.2.0, Kernel 2.4.36.6 und Busybox 1.7.2 tritt das Problem auch auf.

[seife]

Ich kann kein "Problem" erkennen. Das ist "working as designed" bzw. "working as configured".

[Gaucho316]

Wenn das so beabsichtigt ist, dann müssen wir eben damit leben. Aber dass da ständig versucht wird, eine neue Shell aufzumachen, ist doch totaler Unsinn, oder nicht? Kann man das nicht an der entsprechenden Stelle (wo immer das auch ist) mit einem "if (/dev/null) ..." abfangen?

Edit: Oder wir nehmen als Standardwert für "console" in "boot.conf" nicht "null" sondern "ttyS0". Das lässt sich ja ganz einfach in "neutrino.cpp" ändern. Wie wäre es damit?

[Mourice]

Hallo,

naja, es ist ja nicht so, dass der Prozess bei "console=seriell" nicht gestartet wird. Er ist dann nur nicht "defunct", sondern ein zusätzlicher "init-Prozess".

Vielleicht wird ja jetzt der Prozess für "seriell" grundsätzlich mitgestartet und wenn in der boot.conf "null" steht, fehlt das benötigte Device.

Ich kann jetzt nicht sagen, seit wann es so ist, beim Stand vom 31.12.2009 ist es allerdings auch schon "fehlerhaft".

Mit viel Glück liest ja der entsprechende Entwickler hier mit und man muss nicht so lange suchen.

Gruss

[rhabarber1848]

Gegenfrage: Gibt es ein Image, in dem das Phänomen nicht auftritt?

[Mourice]

Gegenfrage: Gibt es ein Image, in dem das Phänomen nicht auftritt?

Hallo,

nur mal so ... es ist kein Phänomen, sondern ein Fehler.

Ich werde mal meine alten Stände testen ... es wäre allerdings produktiver, wenn der entsprechende Entwickler seinen Fehler rückgängig macht.

Gruss

[rhabarber1848]

es wäre allerdings produktiver, wenn der entsprechende Entwickler seinen Fehler rückgängig macht.

U-Boot? Kernel? Busybox? Liegt überhaupt ein Fehler vor?

[dbt]

Ich kann kein "Problem" erkennen. Das ist "working as designed" bzw. "working as configured".

Gegenfrage: Gibt es ein Image, in dem das Phänomen nicht auftritt?

So wie's aussieht nicht.

[Mourice]

Ich kann kein "Problem" erkennen. Das ist "working as designed" bzw. "working as configured".

Hallo,

was anderes kann man von Dir auch nicht erwarten.

Wenn ich Dir eine Box schenke .... kannst Du Dir es dann vorstellen ?

Gruss

[seife]

das ist "working as designed / configured".

In der inittab steht:

Code: Alles auswählen

# this sucks
::askfirst:-/bin/sh

Mach das weg, und das "problem" ist weg, da bin ich sicher.

Allerdings kannst du dich dann auf der seriellen Konsole, so sie dann wieder angemacht wird, auch nicht mehr einloggen.
Fände ich persönlich nicht nützlich.

Dass da jeztt einmal pro sekunde init fork()ed, sich an die Konsole hängen will, dann merkt, dass keine Konsole da ist, und der Prozess dann noch eine Sekunde "herumlungert", bis pid 1 das SIGCHLD bearbeitet, das ist jetzt wirklich kein Problem. Selbst für eine box mit 66MHz und 32MB RAM nicht.

Man könnte jetzt natürlich einen getty an die Konsole hängen, aber das würde nicht weniger Ressourcen fressen, wie einmal eine shell zu starten - und der würde sich entweder auch wieder beenden, wenn keine Konsole da ist oder - noch schlimmer - ewig im Speicher bleiben und selbigen unnötig verbrauchen.

Ich würde es lassen wie es ist und gut.

[seife]

was anderes kann man von Dir auch nicht erwarten.

Wenn ich Dir eine Box schenke .... kannst Du Dir es dann vorstellen ?

Gruss

Laber keinen Quark.

Wenn du konfigurierst "starte bitte eine Shell auf der Konsole", was soll der init dann machen?

Genau, eine shell starten.

Und wenn die sich beendet?

Richtig! Sie neu starten.

Genau das macht init. Defaultmässig schaut er glaube ich 1x pro Sekunde nach ob die Prozesse die gestartet sein sollten, noch laufen.

definitiv liegt ein Fehler vor. Ein "defunct"-Prozess ist ein Fehler.

Weisst du überhaupt, was "defunct" bzw. "zombie" bei einem Prozess bedeutet? Erzähl doch mal.

[seife]

beantworte doch einfach mal meine Frage zum Themq "defunct".

[dbt]

@Mourice
mal noch im Guten, gelbe Karte

[Mourice]

Hallo.

das letzte jetzt zu diesem Thema.

Bei einer bestimmten Einstellung wird permanent ein neuer Prozess gestartet, der dann auch noch in den Status "defunct" geht.
Zu allem Überfluss wird er auch noch permanent neu gestartet.

Das ist definitiv ein Fehler, zumal es dieses Verhalten früher nicht gab.

Dieser Fehler ist hier im entsprechenden Forum gemeldet, und auch noch von "anderen" bestätigt worden.

Normalerweise würde man jetzt einfach nur versuchen, diesen Fehler zu verbessern oder wenigstens einzugrenzen.

Aber nein .... es wird mal wieder versucht, "externe" niederzumachen, sich entsprechend abzugrenzen und zur Not auch noch "gelbe" Karten zu verteilen.

Der "wichtige" Kern lässt einfach keine Kritik zu. Es gibt halt nur die "jetzt" Wichtigen. Nur schade, dass die wirklich Wichtigen mittlerweile gar kein Interesse mehr an dem Projekt haben. Und so können sich jetzt bestimmte "Idioten" als Nachfolger für richtig wichtig halten.

Schon mal bemerkt .... schaut mal auf neue Images und Zugriffe ...

Gruss

[rhabarber1848]

zumal es dieses Verhalten früher nicht gab.

Der Beweis ist afaics noch nicht erbracht. Ein Image von Ende 2008 zeigt bei mir das gleiche Phänomen.

[dbt]

Offtopic: Bevor das wieder uferlos wird, sind die sinnbefreiten Beiträge erstmal entfernt worden.

Und nochmal wegen Zombies, die sind nicht wirklich schlimm und machen nichts kaputt, sind zwar unschön, aber wenn das so belassen wird, nehmen die auch nichts weg.

[Mourice]

Offtopic: Bevor das wieder uferlos wird, sind die sinnbefreiten Beiträge erstmal entfernt worden.

Und nochmal wegen Zombies, die sind nicht wirklich schlimm und machen nichts kaputt, sind zwar unschön, aber wenn das so belassen wird, nehmen die auch nichts weg.

Hallo,

vollkommen richtig. Zombies, die Zombies bleiben sind nur "unschön".

Aber in diesem Fall wird sekündlich ein neuer Zombie erzeugt ... aber Ihr seit ja die "Experten" ....

Aber jetzt soll es gut sein ...

Gruss

[Mourice]

zumal es dieses Verhalten früher nicht gab.

Der Beweis ist afaics noch nicht erbracht. Ein Image von Ende 2008 zeigt bei mir das gleiche Phänomen.

Hallo,

bei Dir gehe ich mal davon aus, dass Du es wirklich getestet hast.

Aber selbst wenn, macht das jetzt den Fehler "korrekt" ?

Gruss

[seife]

Du müsstest die inittab ändern, je nachdem ob console ein- oder ausgeschaltet ist.
Alternativ müsste man init patchen, damit er schaut, ob eine Konsole da ist oder nicht.

Es ist ja nicht so, dass hier jemand gesagt hat "lass uns trulli ärgern und jede sekunde einen Prozess spawnen".

Aber die möglichen Lösungen haben natürlich auch ein paar Nachteile:
* inittab ändern: Wenn das aus irgendeinem Grund fehlschlägt, bootet die Kiste nicht mehr
* init patchen: init ist ein recht spezielles Binary. Es darf keine memleaks haben und es darf keinesfalls crashen, weil beides das system komplett crashen lässt (Kernel panic). Deswegen würde ich ohne Not keine hacks an init vornehmen. Und Not ist hier nicht vorhanden.

Nochmal: einmal pro Sekunde wird eine shell gestartet (die in Form des busybox-Binaries sowieso schon im Speicher ist, es wird also nur eine Kopie erzeugt). Diese beendet sich sofort. In der Zeit, bis der init-Prozess mittels wait() das SIGCHLD abprüft ist diese shell noch als Zombie bzw. "defunct"-Prozess in der Prozessliste zu sehen. In dieser Sekunde (ich glaube, bb-init prüft einmal pro Sekunde auf SIGCHLD) belegt sie noch etwa 4kB an Speicher (ein Eintrag in der Prozessliste, nicht mehr). Ich denke nicht, dass das den Aufwand und die potenziellen Probleme rechtfertigt.

[Gaucho316]

Mein Gott, so eine Lawine wollte ich damit aber nicht lostreten. Ich wollte doch nur, dass meine Netzwerk-LED aufhört zu blinken.

Oder wir nehmen als Standardwert für "console" in "boot.conf" nicht "null" sondern "ttyS0". Das lässt sich ja ganz einfach in "neutrino.cpp" ändern. Wie wäre es damit?

Taugt das denn nun als Kompromisslösung?

[seife]

Mein Gott, so eine Lawine wollte ich damit aber nicht lostreten. Ich wollte doch nur, dass meine Netzwerk-LED aufhört zu blinken.

Du kannst ja nichts dafür, dass trolli deinen Thread übernommen hat

Oder wir nehmen als Standardwert für "console" in "boot.conf" nicht "null" sondern "ttyS0". Das lässt sich ja ganz einfach in "neutrino.cpp" ändern. Wie wäre es damit?

Taugt das denn nun als Kompromisslösung?

Naja, die Kiste bootet dann halt langsamer...

Ich fände das als default sinnvoll, meine Boxen hängen eh alle immer an seriellen Konsolen.

Nur mal so: warum bringt das denn dein Netzwerk in Bewegung? Irgendwas in profile.local? Weil in der defaultkonfig kann ich das nicht wirklich erkennen...


Beim betrachten der inittab ist mir noch folgendes aufgefallen.
Du könntest mal

Code: Alles auswählen

::askfirst:-/bin/sh

durch

Code: Alles auswählen

console::askfirst:-/bin/sh

ersetzen. Aber Achtung! Evtl. bootet die Kiste danach nicht mehr, also einen Weg um das Backup zu flashen solltest du schon haben

[Gaucho316]

Nur mal so: warum bringt das denn dein Netzwerk in Bewegung? Irgendwas in profile.local? Weil in der defaultkonfig kann ich das nicht wirklich erkennen...

Ja, in profile.local erweitere ich die Umgebungsvariable PATH um ein bin-Verzeichnis, dass auf der WL-HDD liegt. Hier teste ich gerne mal selbst generierte Neutrino-Binaries.

[rhabarber1848]

Code: Alles auswählen

console::askfirst:-/bin/sh

Die Box bootet noch, allerdings existiert das Phänomen weiterhin:

Code: Alles auswählen

~ # ps -ef | grep init | grep -v grep
root         1     0  2 01:59 ?        00:00:01 init      
root        25     1  0 02:00 vc/2     00:00:00 init      
root        26     1  0 02:00 vc/3     00:00:00 init      
root       289     1  0 02:00 ?        00:00:00 [init] <defunct>
~ # ps -ef | grep init | grep -v grep
root         1     0  2 01:59 ?        00:00:01 init      
root        25     1  0 02:00 vc/2     00:00:00 init      
root        26     1  0 02:00 vc/3     00:00:00 init      
root       293     1  0 02:00 ?        00:00:00 [init] <defunct>
~ # ps -ef | grep init | grep -v grep
root         1     0  1 01:59 ?        00:00:01 init      
root        25     1  0 02:00 vc/2     00:00:00 init      
root        26     1  0 02:00 vc/3     00:00:00 init      
root       297     1  0 02:00 ?        00:00:00 [init] <defunct>
~ # ps -ef | grep init | grep -v grep
root         1     0  1 01:59 ?        00:00:01 init      
root        25     1  0 01:59 vc/2     00:00:00 init      
root        26     1  0 01:59 vc/3     00:00:00 init      
root       304     1  0 02:00 ?        00:00:00 [init] <defunct>

[dbt]

Ich habe hier seltsamerweise kein <defunct>, benutze allerdings eine eigene busybox hier in Yadd:

Code: Alles auswählen

dbt@linux-11-1:~> telnet
telnet> open 192.168.1.22
Trying 192.168.1.22...
Connected to 192.168.1.22.
Escape character is '^]'.

Nokia D-BOX2 - Kernel 2.4.37.9-dbox2 (21:24:44).
dbox login: root


BusyBox v1.16.1-git.novatux (2010-07-12 09:50:08 CEST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

~ > ps -ef | grep init | grep -v grep
    1 root       540 S    init
   20 root       580 S    /bin/sh /etc/init.d/rcS
   21 root       540 S    init
   22 root       540 S    init
   23 root       540 S    init
  240 root       520 S    /bin/sh /etc/init.d/start_neutrino

[rhabarber1848]

Im CVS-Image heißt der defunct-Prozess "sh", mit den von seife vorgeschlagenen Änderungen ist es "init".