FERTIG...Samba aus usb labor 8221 läuft mit 7170 u. 7141 bis 04.40

[Darkyputz]

also wenn ich den befehl

kill `pidof /etc/init.d/rc.S`

eingebe, kommt da hier

sh: kill: line 1: usage: kill [-s sigspec | -signum | -sigspec] [pid | job]... or
kill -l [exitstatus]

 

[RalfFriedl]

Das Problem ist, daß es sich um ein Skript handelt. Es gibt kein Programm, daß /etc/init.d/rc.S heißt, sondern nur /bin/sh. Unter dem Namen laufen aber alle Shells.

Wie ich schon geschrieben habe, kann man sich um die Automatisierung immer noch Gedanken machen, sobald man weiß, daß das Stoppen an sich hilft.

 

[olistudent]

Habt ihr eigentlich den Schuldigen schon gefunden? Kannst du nichtmal ein paar Sachen deaktivieren um zu schauen wer die Zombies verursacht und fang am Besten mit deinem Samba-Package an. :mrgreen:

MfG Oliver

 

[Darkyputz]

@olli
an meinem ding iss nix abzuschalten...das nen run_mount/storage automatisssmus...keine andere logik vorhanden...
wenn man es daher irgendwo rausnhemne kann aus einer was auch immer ausführenden logic, würd ich das gern tun...aber wie...bin doch hier von euch allen der nix blicker

 

[olistudent]

Sind die Zombies denn noch da, wenn du deinen USB-Speicher entfernst?

MFG Oliver

 

[Darkyputz]

ok...hier also meine ergebnisse...
neustart mit usb datenträger: zombies
neustart ohne usb datenträger: zombies
neustart ohne usb datenträger ohne btftpd: zombies
neustart ohne usb datenträger ohne btftpd, callmonitor: zombies
neustart ohne usb datenträger ohne btftpd, callmonitor, spindown: KEINE zombies

das rc.S script und die zombies bleiben nach weiteren tests immer dann wenn spindown mit dem mod automatisch mitstartet...
lasse ich es weg(kein autostart) dann läuft alles ohne zombies hoch...
auch ein usb datenträger entfernen ist dann ohne zombies und mit ordnungsgemässem stoppen des nmbd/smbd.
ein wiedereinstecken läuft auch ohne zombies und ordnungsgemäss ab...
ich stelle daher fest:
wenn prozesse auf den stick zugreifen wie nen log oder der spindown, läuft beim hochfahren einiges nicht sauber durch und beim trennen kann er dann nicht den mountpoint beenden da er wohl in benutzung ist...ohne spindown(also ohne dienst der den usbdatenträger belegt) läuft dann alles durch und auch rc.S iss sauber beendet und es gibt keine zombies...
werde wohl noch etwas mit spindown testen, aber wenn das sich weiter so verhält, muss ich es wohl später mit crond starten lassen...ein ähnliches problem macht ja dtmf auch...

hoffe ihr könnt das verifizieren...hat aber nix mit meinem addon zutun...glück gehabt *GRINS*

 

[kriegaex]

Du kannst zum Debuggen unter packages die Datei rc.spindown mal so modifizieren, daß sie jeden von der Shell ausgeführten Befehl ausgibt und außerdem gleich sämtliche Ausgaben in eine Datei schreibt. Dazu änderst Du einfach erste Zeile und fügst darunter eine weitere ein:

#!/bin/sh [COLOR="Blue"]-x
exec 1>/var/rc-spindown-log.txt 2>&1[/COLOR]

Dann kannst Du Dir ja mal in Ruhe hinterher anschauen, wo er hängen bleibt. Übrigens habe ich auf die Schnelle schon eine Passage gefunden, die im RC-Skript nicht tut, was sie dem Augenschein nach tun soll (ungetestet, nur den Code überflogen):

...
start() {
	checksysfs
	echo -n "Starting $DAEMON..."

	$DAEMON $SPINDOWN_DEVICE $SPINDOWN_IDLETIME $SPINDOWN_MODE [COLOR="Red"]&
	exitval=$?[/COLOR]
	sleep 1
	if [ -f /var/run/$DAEMON.$SPINDOWN_DEVICE.pid ]; then
		echo 'done.'
	else
		echo 'failed.'
		[COLOR="red"]exit $exitval[/COLOR]
	fi
}
...

Die Variable exitval erhält immer den Wert 0 und nie einen evtl. Fehlerwert von Spindown, weil der Befehl ja im Hintergrund ("&" am Zeilenende) ausgeführt wird und gar nichts mehr synchron an das aufrufende Skript zurückgeben kann. D.h., im Fehlerfall wird zwar "failed" geschrieben, aber 0 zurückgegeben vom Start-Skript. Das ist wohl nicht für die Zombies verantwortlich, aber nichtsdestoweniger falsch. Nicht mein Skript, zum Glück... ;-)

 

[Haeberle]

Hi zusammen,

bin aus dem Urlaub zurück, hab mal den Inhalt des Threads mir reingezogen, und dann sanft wie ein Berserker den Spindown-Dienst gestoppt (also kein Deaktivieren und Box neu starten, sondern nur DS-MOD-mäßiges "Dienst beenden")

Ergebnis:
- Vorher ca. 50 Zombies (basename, sh, callmonitor, smbd, nmbd, ftpd ... you name it)
- Nachher NIX! Keine Zombies, GAR keine. Wirklich.

Fragt sich der Laie: Was verursacht die Zombies?

EDIT: Folgende Beobachtungen:
- Spindown beim Hochfahren der Box automatisch mitgestartet (mit oder ohne usb-device ist egal): Zombies (auch multid u.a., und es werden immer mehr). Auch der Login per Telnet fragt mich *nicht* nach dem Login-Namen!
- Spindown per rc.spindown gestoppt und wieder gestartet: Keine Zombies, auch zukünftig nicht. Telnet fragt mich nach dem Login-Namen.
- Spindown deaktiviert und von Hand gestartet: Ebenfalls keine Probleme

Für mich ist das manuelle starten des Spindown erstmal die Lösung. Das Script scheint noch weitere Bugs zu haben, wie beispielsweise die Tatsache, dass kein .pid-File erzeugt wird, wenn das Device gar nicht vorhanden ist, und dann aber weiterläuft. Mangels PID-File bringt dann "rc.spindown status" ein "stopped" (auch die DS-MOD-Oberfläche), aber der Dienst läuft trotzdem noch laut ps.

Kann es auch sein, dass die verschiedenen Fehlerkonditionen (kein Device vorhanden, kein sysfs vorhanden) falsch behandelt werden? Mir scheint es mit meinen bescheidenen Fähigkeiten so, dass beim Hochstarten der Box der ganze Test, ob sysfs vorhanden ist, fehlschlägt. Das müssen aber Leute testen, die sich besser auskennen.

@Darky: Dein Addon scheint es nicht zu sein ...

Grüße,

Arndt

 

[RalfFriedl]

Fragt sich der Laie: Was verursacht die Zombies?

Dazu steht schon etwas in Beitrag #20 und den folgenden. Wenn das zu ungenau ist, bitte konkreter fragen.

Es ist normal, daß es entweder immer mehr Zombies gibt oder gar keine.

Es ist auch normal, daß das gleiche Skript, wenn es nicht (direkt oder indirekt) von /ect/init.d/rc.S gestartet wird, keine Zombies mehr verursacht.

 

[Darkyputz]

bei mir iss es so, das wenn spindown per hand gestartet wird keine zombies vorkommen...meinstdu das?
wenn spindown per rc.S gestartet wird, werden es immer mehr zombies..mit jeder aktion, die getätitgt wird, solange, bis rc.S abgeschossen wird, da sie nie zuende läuft...
sicherlich fehlt da nur nen termierung befehl, von wegen spindows iss da...oder fertig oder sowas...ich denke das rc.S auf was watetet

 

[RalfFriedl]

/etc/init.d/rc.S ruft unter anderem debug.cfg und /etc/init.d/rc.mod auf.
/etc/init.d/rc.mod ruft unter anderem nacheinander alle Start-Skripte auf, die in /etc/static.pkg genannt sind. Nacheinander heißt, es wird das erste aufgerufen, gewartet, bis es beendet ist, dann erst wird das nächste aufgerufen, und so weiter.
Wenn jetzt irgend eines der gestarteten Skripte nicht beendet wird, dann wird auch /etc/init.d/rc.mod und folglich /etc/init.d/rc.S nicht beendet.
Solange aber /etc/init.d/rc.S nicht beendet wird, bleibt jeder beendete Prozeß als Zombie übrig.

Diese Situation, daß /etc/init.d/rc.S nicht beendet wurde, läßt sich dadurch ändern, daß /etc/init.d/rc.S gekillt wird. Damit hat man aber nicht die Ursache beseitigt, in diesem Fall den Fehler im Spindown Skript. Das hatte ich schon in Beitrag #30 geschrieben.

Sobald aber /etc/init.d/rc.S beendet ist, ob durch killen von /etc/init.d/rc.S, von /etc/init.d/rc.mod oder von Spindown Skript, oder bevorzugt durch Korrektur des Spindown Skripts, verschwinden ersten alle Zombies Prozesse, nicht nur einige davon, und zum anderen bleiben auch bis zum nächsten Neustart keine mehr übrig. Unabhängig davon, ob und auf welche Weise und wieviele fehlerhafte Spindown Skripts aufgerufen werden.

Solange /etc/init.d/rc.S nicht beendet ist, bleibt jeder beendete Prozeß als Zombie übrig. Unter anderem ein Prozeß für jeden Zugriff auf den httpd Server. Deswegen hatte ich in Beitrag #26 empfohlen, probehalber einige beliebige Seiten aufzurufen.
Meine Box hat in der Standardeinstellung ein Limit von 1408 Prozessen. Für den normalen Betrieb ist das mehr als ausreichend. Wenn aber diese Grenze irgendwann durch Zombie-Einträge erreicht wird, kann überhaupt kein neuer Prozeß mehr gestartet werden.

Es ist daher sehr wichtig, bei den Start-Skripten darauf zu achten, daß diese korrekt beendet werden.

 

[Haeberle]

Bitte den Smiley beachten - für mich war damit klar, welches Script Schuld war (und nochmal einer )

Aber nochmal Danke für den großen Zusammenhang, der war mir nämlich noch nicht klar - also das mit rc.S, und den scheinbar damit nicht zusammenhängenden Zombies (multid), die aber alle in der rc.S ihren Ursprung haben. Ich glaube, jetzt hab auch ich Idiot das gecheckt.

Hat schon jemand den Vorschlag von kriegaex zum Debuggen des spindown-Scripts anwenden können? Ich würde es ja mal ausprobieren, hab aber erst wieder kommendes Wochenende Zeit.

 

[Haeberle]

Ralf, noch eine Frage zum Thema "Script wird nicht terminiert". Spindown ist ja ein Dämon, und wird als Script realisiert, welches endlos läuft. Es wird gestartet und mit "&" in den Hintergrund gelegt.

Seh ich das also richtig:

rc.S startet
rc.mod startet
rc.spindown startet
spindown &

Jetzt meine Frage: Ist unser Problem vielleicht die Tatsache, dass spindown (als Daemon) per Definition endlos läuft? Ist das die korrekte Vorgehensweise, wenn spindown mit "&" in den Hintergrund gelegt wird? Oder muss noch was spezielles unternommen werden, damit die Ausführung von rc.S nicht deshalb als "nicht abgeschlossen" angesehen wird, weil "spindown" in einer Schleife läuft?

Nur die Vermutung eines Laien.

Danke & Grüße,

Arndt

 

[RalfFriedl]

Es ist ja unter anderem Aufgabe der Start-Skripte, andere Prozesse zu starten, die als Daemon endlos laufen sollen. Das ist also kein grundsätzliches Problem.

Ein vergessenes "&" nach dem Aufruf ist der häufigste Grund dafür, daß rc.S nicht beendet wird. Hier fehlt es jedoch nicht.

In der mod.log von Darkyputz in #27 ist auch zu sehen, daß das Start-Skript für spindown schon recht früh gestartet wird und auch beendet wird.

Im Moment ist mir nicht klar, was genau der Grund dafür ist. Die Beobachtung von kriegaex in #47 ist zwar richtig, bewirkt jedoch nur, daß der Rückgabewert des Skripts falsch ist. Dieser wird jedoch in rc.mod nicht verwendet. Daher hat dieser Fehler keine weitere Bedeutung.

 

[olistudent]

Bei mir hat folgendes geholfen:

--- rc.spindown.old     2007-09-23 23:49:32.000000000 +0200
+++ rc.spindown 2007-09-23 23:49:27.000000000 +0200
@@ -43,7 +43,7 @@
        checksysfs
        echo -n "Starting $DAEMON..."
-       $DAEMON $SPINDOWN_DEVICE $SPINDOWN_IDLETIME $SPINDOWN_MODE  &
+       ($DAEMON $SPINDOWN_DEVICE $SPINDOWN_IDLETIME $SPINDOWN_MODE > /dev/null 2>&1) &
        exitval=$?
        sleep 1
        if [ -f /var/run/$DAEMON.$SPINDOWN_DEVICE.pid ]; then

MfG Oliver

 

[Haeberle]

Hallo,

olistudents Lösung funzt - hab es grade nochmal kurz ausprobiert. Klasse! Vielen Danke!

Also lag es an den Fehlermeldungen oder am stdout? Wer kann das erklären?

[Edit: Mensch, bist Du fix. Das mit dem "verfrachtet" hatte ich gerade schon ergoogelt und wieder rausgenommen ]

Danke & Grüße,

Arndt

 

[olistudent]

Die Ausgabe wird ins nichts verfrachtet. Den selben Effekt hat man, wenn man die Standard- und Fehlerausgabe in dem Skript schließt (exec 1>&-). Das Problem tritt bei allen Dämon-Skripten auf.

MfG Oliver

 

[Darkyputz]

na wenn das nicht gut klingt...fliesst das in die 15.3 ein?

 

[kriegaex]

Nein, wir hassen Verbesserungen. ;-) Ja, das wird einfließen. Ich habe schon vor Monaten mal ein Daemon-Skript mit Oliver kurz andiskutiert, nachdem ich in der BusyBox-Mailingliste mal mit dem BB-Autor darüber geredet hatte, was man da beachten muß. Ist nur wieder in Vergessenheit geraten. Ob wir da so eine Art allgemeinen Wrapper basteln oder einfach punktuell die Ausgabeumleitung verwenden, wo nötig, haben wir noch nicht besprochen.

 

[RalfFriedl]

Ein Daemon-Programm (oder auch ein Daemon-Skript) sollte sich selbst darum kümmern, sich vom Terminal zu trennen und in den Hintergrund zu gehen.

Leider machen das einige Programme nicht richtig, und bei Skripten ist es auch etwas schwieriger, in den Hintergrund zu gehen.