Green-LED-Blinking PowerOff Bug

  • wollte kurz feedback geben, dass ich in einem monat mit

    Code
    sync # filesysteme wird gesynct
    echo u > /proc/sysrq-trigger # filesysteme werden readonly gemountet
    echo o > /proc/sysrq-trigger # poweroff

    keinen hang mehr hatte. die box macht jede nacht automatischen epg refresh und 4 aufnahmen... wird also jeden tag mindestens 5 mal ausgeschaltet.


    hier die /usr/bin/enigma2-system-state file:

  • Ich wollte eigentlich NICHTS mehr DAZU schreiben, aber nachdem du scheinbar drauf bestehst deinen Blödsinn weiter zu posten:


    Mache BITTE wenigstens 2x sync, weil es ist so ziemlich das DÜMMSTE was man machen kann zuerst einen sync anzustarten damit der kernel anfängt den cache zu schreiben und dann sofort die CPU anzuhalten ohne zu wissen ob er damit fertig ist.


    WENN dann sollte man zumindestens 2x sync kurz hintereinander machen, weil der zweite sync dann hängen bleibt wenn der erste noch nicht fertig ist und das SCHLIMMSTE dadurch wenigstens verhindert wird wenn du anschließend alles totschlägst im Glauben damit Probleme zu "Lösen"


    Und nein hier gibt es keine Lieben Grüße mehr

    gutemine

  • Wenn du das für einen Mythos hältst ... dann verteile halt weiter Streichhölzer an Kinder....

  • Alphas shutdown / power down script "enigma2-system-state"


    Ich habe das modifizierte "/usr/bin/enigma2-system-state" script von alpha mal ausprobiert

    indem ich mein timer test script (siehe Nachricht #6 aus diesem Thread) mal über 2 Tage habe

    laufen lassen (insgesamt fast 1000 Power Offs / Restarts).


    Und was soll ich sagen. Die Box ist beim Shutdown nicht ein einziges mal hängen geblieben.

    Das spricht eindeutig für diese Änderung!


    Was allerdings schon beim Beobachten der Box auffiel. Das Runterfahren mit anschließen-

    dem Power Off braucht viel weniger Zeit als beim Original Script.


    Die Ursache sieht man wenn man sich die LOGS bei ungeänderten und modifizierten Script

    mal ab Shutdown Start ansieht.


    Vergleicht man beide LOGS (entnommen der USB Debug Schnittstelle der Box (siehe An-

    hänge)), dann sieht man, das ein Großteil der Prozesse nicht mehr regulär beendet wird.

    Das stört bei den meisten der Prozesse wahrscheinlich nicht, da diese beim erneuten

    Start der Box wieder sauber hochgefahren werden.


    Bei einigen ist dies wahrscheinlich schon kritischer. Nämlich bei solchen die eine Verbindung

    zur Außenwelt haben. Netzwerkprozesse z.B. wie der SMB. Hier hat der Prozess nämlich

    keine Möglichkeit mehr die Verbindung zu einem externen Server korrekt zu schließen.


    Ob das im wahren Leben tatsächlich ein Problem ist, kann ich nicht beantworten. Dafür bin

    ich zu wenig Linux Spezialist. So richtig wohl würde ich mich aber bei einer dauerhaften

    Scriptänderung nicht fühlen.


    Wenn Alpha mit den Änderungen keine nachteiligen Erfahrungen gemacht hat, spricht nichts

    dagegen sie weiter zu verwenden. Es ist auf jeden Fall eine einfache Möglichkeit diesen power

    down crash zu umgehen.


    Ich bleibe aber sicherheitshalber bei meinen Nannies.


    /Willi/


    PS: Was man aber auch sieht ist, dass einer der durch das reguläre Script beendeten Prozesse

    für den gelegentlichen Kommunikationsverlust zwischen Main - und Frontprozessor verantwortlich

    sein muss. Die Frage ist nur: Welcher?

  • danke fuers feedback.

    wie schon gesagt, ist das ein relativ brutaler workaround fuer das hang-problem bis dream das problem richtig fixed.


    p.s. was mir auch noch aufgefallen ist: die box schaltet sich schneller ein. ohne workaround dauert es ca. 2-3s, bis die blaue led nach druecken der power-on taste auf der rc angeht. mit dem workaround geht die led sofort an 😁

    Einmal editiert, zuletzt von alpha ()