Nokia 2xI Avia600 Kabel bleibt beim Reboot hängen

[gurgel]

du meintest wohl Gorcon

[mumdigau]

Erfolg! Endlich klappt der Reboot. Ich habe mal das, was hier und in anderen Threads an Ideen rumgeisterte, miteinander verbunden. Diese Sequenz funktioniert (zumindest bei meiner Nokia).

killall -9 sectionsd
killall -9 camd2
killall -9 timerd
killall -9 controld
killall -9 nhttpd
pzapit -kill
killall -9 tuxmaild
killall -9 start_neutrino
killall -9 neutrino
busybox -reboot

Vielleicht kann man das noch vereinfachen, aber ich hab's einfach so in ein Script gepackt und kann damit die Box sauber rebooten. Hab's auch so da, wo es gebraucht wird, in mein Flexmenü eingebaut: Klappt wunderbar.

Vielen Dank an alle für ihre Beiträge.

mumdigau

[mogway]

[...] und kann damit die Box sauber rebooten.

Naja, sauber würde ich es nicht nennen, wenn man die Prozesse mit Gewalt beendet.

Gruß
mogway

[mumdigau]

[...] und kann damit die Box sauber rebooten.

Naja, sauber würde ich es nicht nennen, wenn man die Prozesse mit Gewalt beendet.

Gruß
mogway

Meines Wissens ist 'kill' der Standard-Befehl in UNIX zum Beenden eines Prozesses. Kennst Du etwas saubereres?

FG

mumdigau

[saruman]

Ja, aber kill -9 (Signal KILL) ist für den Prozess so, als würdest Du den Stecker aus Deiner Box ziehen. Nimm mal alle -9 raus, dann sieht das schon besser aus.

[Barf]

Der Unterschied zwischen kill (defaltsignal ist TERM) und kill -9 ist wie der Unterschied zwischen "Bitte aufhören" und ein Messer in den Rücken. Mannomann habe ich viele "Anleitungen" und "Howtos" gelesen, wo "kill -9" empfolen wird.

Wenn ein Programm ein Signal (außer KILL) empfängt, macht es oft diverse Aufräumungsaubeit, lock-Files zu löschen, Konfigurationsdatein abspeichern. Falls ein Programm sich nur mit KILL (=9) sich beenden läßt (sowas passiert) "hängt es", in der Regel als Bug zu betrachten.

[mumdigau]

OK. Wieder was dazu gelernt. Ehrlich gesagt kannte ich den Parameter '-9' für killall gar nicht. Das war ein Tip von @jmittelst hier in diesem Thread. Ich bin mit UNIX aber auch nicht wirklich vertraut. Ich ersetze also in meiner obigen Aussage 'sauber' durch 'erfolgreich'.

Ach ja, wenn ich alle '-9' wegnehme, bleibt die Box im Reboot hängen!

mumdigau

[jmittelst]

Möglichkeit: Alle mit Kill beenden, nachschauen, was noch läuft und das dann wirklich mit killall -9 wegbomben. Andere Lösung: Jemand, der besonders viel Checkung hat, schaut sich das mal ganz genau an und korrigiert ggf. den Code, der das Abschießen nötig macht. Laut Aussage von Barf muß da ja ein Bug sein, wenn ein killall -9 nötig ist, um einen Prozess abzuballern.
cu
Jens

[mumdigau]

Möglichkeit: Alle mit Kill beenden, nachschauen, was noch läuft und das dann wirklich mit killall -9 wegbomben. Andere Lösung: Jemand, der besonders viel Checkung hat, schaut sich das mal ganz genau an und korrigiert ggf. den Code, der das Abschießen nötig macht. Laut Aussage von Barf muß da ja ein Bug sein, wenn ein killall -9 nötig ist, um einen Prozess abzuballern.
cu
Jens

Gute Idee. Ich werde mal versuchen herauszufinden, welcher Prozeß denn verhindert (und deshalb '-9' erfordert), daß der Reboot klappt.

Dennoch schießt meines Erachtens die Kritik von @Barf ein wenig über das Ziel hinaus. Ich bin auch für saubere Lösungen. Aber manchmal geht es halt nicht anders, als den Knüppel herauszuholen. In Windows z. B. gibt es eigens entsprechende Einstellungen, die erlauben einzustellen, wie mit Anwendungen zu verfahren ist, die beim Herunterfahren nicht innerhalb einer festgelegten Zeit auf eine ordnungsgemäße Terminierung reagieren; diese werden dann gekillt. Und das hat nicht immer was mit Bugs in den Programmen zu tun. Programme z. B. , die vom Funktionieren bestimmter Teile des Operation Systems abhängig sind, geraten in Schwierigkeiten - und reagieren daher nicht mehr korrekt beim Herunterfahren -, wenn rebootet wird, und das ist nicht immer programmtechnisch abzufangen. Dafür sind die heutigen Systemkonfigurationen viel zu komplex geworden. Genau deshalb hat Windows diese Funktionalität eingebaut, schließlich soll ja letztlich heruntergefahren werden. Und: seriöse Programme sichern wichtige Einstellungen nicht erst beim Beenden, sondern in regelmäßigen Abständen während des laufenden Betriebs, sodaß bei einem solchem kill relativ wenig verloren geht

Daher lautet mein Fazit: So sauber wie möglich, so drastisch wie nötig.

mumdigau

P.S. Gibt es eigentlich unter UNIX auch so was wie ein verzögertes Kill analog zu Windows?

[saruman]

P.S. Gibt es eigentlich unter UNIX auch so was wie ein verzögertes Kill analog zu Windows?

Nicht dass ich wüsste. Müsste man verskripten:

Code: Alles auswählen

killall <PROCESSNAME>
sleep 30
if pidof <PROCESSNAME>; then
  killall -9 <PROCESSNAME>
fi

Irgendwie so.

[rolanddata]

Hallo allesamt,

weiss nich obs hilft, aber meine Nokia (Avia600) rebootet, nachdem ich mir ein shell-script namens "reboot" in /var/bin gebaut habe. Leider bin ich nicht zu Hause und Box is aus. Kann mich aber erinnern, dass da 4 oder 5 killall's drin waren. Allerdings Kein -9.

Meistens klappt es nun bei mir.

Grüße,
RData

[mumdigau]

... nach vielen, vielen Reboots:

Ich habe (m)eine optimierte Script- Fassung ermittelt. Bis auf controld und tuxmaild konnte ich alle anderen killall's rausschmeißen. Bei den verbliebenen muß ich allerdings '-9' setzen, sonst bleibt die Box hängen. @Sarumans Vorschlag des "verzögerten" killall -9 (also erst killall und dann, wenn der Prozeß nach einer gewissen Zeit noch nicht beendet ist, killall -9) klappt hier nicht: Die Box bleibt wieder hängen.

Hier also meine Fassung:

#!/bin/sh
killall -9 controld
killall -9 tuxmaild
busybox -reboot
exit;

FG

mumdigau

[saruman]

Jau, das mit dem "verzögerten" kill war auch nur so ganz schnell runtergehackt. Bin mir nicht mal sicher, dass das überhaupt so funktioniert.

Also der tuxmaild braucht normalerweise kein KILL, dem reicht ein einfaches TERM um sich zu beenden. Allerdings will er dann noch die Mailliste nach /var/tuxbox/config/tuxmail speichern und benötigt deswegen noch ein paar Sekunden.

An sich müsste daher sowas wie

Code: Alles auswählen

kill $( cat /tmp/tuxmaild )
killall controld

N=0
while [ $N -lt 10 ]; do
  pidof tuxmaild && echo "waiting for tuxmaild to shut down"
  pidof controld && echo "waiting for controld to shut down"
  N=$( expr $N + 1 )
done
pidof tuxmaild && killall -9 tuxmaild
pidof controld && killall -9 controld

besser funktionieren.

Obwohl, wenn ich's mir recht überlege ist das das gleiche wie oben, nur schöner.

[mumdigau]

Obwohl, wenn ich's mir recht überlege ist das das gleiche wie oben, nur schöner.

Du hast Recht (zweimal). In meinen Tests hatte ich tuxmaild 10 sec. Zeit gegeben, Abschlußarbeiten zu verrichten und sich sauber zu verabschieden (sleep 10). Leider half trotzdem nur die '-9'-Keule, ebenso bei controld. Es gibt zwar wichtigeres, aber über kurz oder lang sollte einer der Devs diese Unsauberkeit mal bereinigen.

FG
mumdigau

[Barf]

Ich habe es geschafft, den größten Teil des Sonntags mit diesem blöden Problem zu vernichten ...

Fakten:

- Das reboot-Befehl hängt bei viele (nicht alle!) Nokias,
- Sowohl bei AVIA 500 als 600.
- Das Problem ist das reboot-befehl (in busybox implementiert).
- Falls "alle" Prozessen in voraus getötet wird, klappt es, am mindestens oft. Dies ist keine Lösung, möglicherweise ein Workaround. Dabei ist es natürlich (hier) nebensäcklich mit welche Signale die Prozesse getötet wird.
- also ist das Problem entweder in busybox oder im Kernel
- aufruf von dem Systemcall reboot(RB_AUTOBOOT) in einem eigenem Programmchen rebootet erfolgreich:

Code: Alles auswählen

#include <unistd.h>
#include <sys/reboot.h>

int
main() {
  reboot(RB_AUTOBOOT);
}

Sollte mann vielleicht reboot als eigenständige Programm implementieren?

[MB]

Erklärt das vieleicht warum meine Nokia statt einem Reboot zu 99% nach ner weile einfach ausgeht, statt neuzustarten? Ich glaube meine zweite (verkaufte) Nokia tat dies auch. Wobei meine Philips dies kann (neustarten)