DM900 kommt nicht aus Standby hoch

  • Hallo, wenn ich meine DM900 über die Fernbedienung in den Stnadby schicke und kurz darauf wieder Power on schalte funktioniert alles wie es soll.
    Wenn ich aber am nächsten Tag die Box einschalten will geht nichts mehr.


    - Keine Reaktion auf Powertaste
    - kein Power on über WebIF (Box mit IP nicht mehr im Netzwerk sichtbar)
    - keine Reaktion auf die Fernbedienung


    Mit dem EIN / AUS Schalter auf der Rückseite startet sie normal aber kein Crashlog.


    Danach habe ich das Image neu geflashed (kein Elektro Plugin), automatisches Poweroff aus. Aber trotzdem kommt sie dann nicht hoch auch nicht für Timer.


    Hat jemand sowas schon gehabt / erlebt?

  • Wenn das mit der FB und der Power Taste an der Front nicht geht, hört sich das stark nach Hardwareproblem an.


    WebIF geht natürlich nicht im StandBy, weil dann ist ja alles aus.
    Standby = früher DeepStandby
    Idle = früher Standby
    Nicht das wir aneinander vorbei reden. :winking_face:

  • Hallo Swiss-MAD, danke für deine Antwort und die Info mit dem Idle, Standby.


    Also es geht um den Idle-Mode. Ich habe das Gefühl das die Box (warum auch immer) irgendwann im Idle-Mode einfriert. Kann ich das nach dem Booten in den log-Dateien sehen?
    Du hast Recht, in der Netzwerkumgebung sehe ich sie im Standby nicht mehr.


    Folgende Einstellungen habe ich nochmal Überprüft:
    Hauptmenü --> Einstellungen -->Menü --> Anpassen:


    Herunterfahren nach einer Inaktivität von = deaktiviert
    Aktion bei kurzen Druck auf Power = Idle Mode

  • Ok so kommen wir schon mal weiter. Sie bleibt also im Idle Mode irgend wann hängen.


    1. Welches Image verwendest du ? Meine Empfehlung vor allem für den Test das aktuelle Unstable Image von Dream
    2. Im Betrieb hattest du das Problem noch nie ?
    3. Hast du über Nach was laufen wie z.b. EPG-Refresh oder so was, woran die Box dann hängen bleibt ?
    4. Was für eine Uhrzeit steht im LCD bevor du sie anmachen willst ? Weil wenn Enigma2 hängen bleibt, hast du auf dem LCD in der Regel noch die Uhrzeit wann das passiert ist.
    Wenn du Komponenten über HDMI angeschlossen hast die in der Nacht irgend was anstellen, kannst du zum Test auch mal über Nacht das HDMI Kabel von der Box abziehen. (Eher unwahrscheinlich, aber man weiss ja nie. ;))


    Ich vermute mal das nur Enigma2 hängen bleibt, das System noch weiter läuft.
    Das findest du raus, wenn du eine Telnet Verbindung aufbaust. Geht auch das nicht, ist das komplette System flach.
    Wenn Telnet noch geht kannst du die letzten Kernel Meldungen mit dem Befehl dmesg abrufen. (auch das kannst du in eine Datei umleiten wie am Ende beschrieben)


    Für ein komplettes Log kannst du nachdem die Box in den Idle geschickt wurde, von da an ein E2 Log machen lassen, und das dann am nächsten Tag auf den PC kopieren.
    Damit sollte man raus finden was passiert ist.
    Das geht mit dem Befehl journalctl -f -u enigma2 > /tmp/enigma2.log & über Telnet.


    journalctl -f -u enigma2 gibt alle Logmeldungen vom Task enigma2 aus.
    > /tmp/enigma2.log leitet die Bildschirmausgabe in die Datei enigma2.log nach /tmp/ um. (/tmp/ ist im RAM, aber das ist bei der 900er gross genug und so viel sollte in der Nacht nicht passieren. :winking_face: )
    Das & ist dafür da, das das Log weiterlauft auch wenn du die Telnet Sitzung beendest.


    Eben ausprobiert, und trotz & wird bei mir journalctl beim schliessen der Telnet Sitzung gestoppt.
    Ein journalctl -f -u enigma2 > /tmp/enigma2.log & disown
    oder
    nohup journalctl -f -u enigma2 > /tmp/enigma2.log &


    Müsste den Task eigentlich weiter laufen lassen, tat es aber bei mir nicht. Sobald ich die Telnet Sitzung geschlossen hatte, war der Task auch weg.
    Phuuu...über Nacht hatte ich noch nie geloggt, keine Ahnung weshalb trotz diswon oder nohub es nicht geht......jeder Tipp ist willkommen. :confused_face:

  • Hallo Swiss-MAD, vielen Dank. :tongue:


    EPG Refresh ist ein guter Tipp. Ich habe vorgestern das Image neu geflashed und zwar gemini-unstable-OE25-image-dm900-20170217202107, also das unstable mit GP3. Danach alle Updates geladen.


    Zur Zeit laüft es. Das bedeutet aber auch ich kann den Fehler nicht nachstellen.


    Ich werde aber EPG-Refresh testen, da das noch nicht konfiguriert ist und nicht läuft.
    Was funktioniert ist Standby nach einer Stunde und dann mit der FB oder Powerstaste starten.


    Eigentlich würde ich sagen es läuft aber ich weis jetzt nicht warum.


    Hast du "nohup journalctl -f -u enigma2 > /tmp/enigma2.log &" über telnet oder ssh probiert?


    Ich werde übers Wochenende testen. :tongue:

  • Ist ja schön das es läuft. Wäre aber interessant gewesen was es war. Naja, Hauptsache läuft wie es soll.


    Telnet ist unverschlüsselt, SSH verschlüsselt. Das ist mehr oder weniger der Unterschied.
    Im Lokalen Netz sowieso kein Problem, ich verwende nur Telnet, und von Extern geht bei mir alle nur über VPN. :winking_face:

  • Swiss-MAD


    Ich habe das mal gerade bei mir auf der DM7080 getestet mit aktuellen DreamOS 2.5 unstable


    Code
    journalctl -f -u enigma2 > /tmp/enigma2.log &


    Wenn ich Putty beende per "Exit" wird bei mir trotzdem der Log weitergeschrieben.


    Kannst du mir nun verraten wie ich den Log wieder beenden kann ohne die Box neu zu starten?
    Wenn ich mich erneut per Putty einlogge und Strg+C eingebe kommt nur ein


    l

    Code
    login as: root
    root@192.168.178.33's password:
    root@dm7080:~# ^C
    root@dm7080:~#
  • Prozess identifizieren und die PID killen
    z.B. ps -ef | grep journalctl
    dann kill 1234 (PID von journalctl)

    Gruß JOE

    Einmal editiert, zuletzt von Flower ()

  • Zitat

    Original von Flower
    Prozess identifizieren und die PID killen
    z.B. ps -ef | grep journalctl
    dann kill 1234 (PID von journalctl)


    einfacher und genauso effektiv


    killall -9 journalctl


    wenn man es über die PID anstatt über den Prozessnamen machen will geht es auch einfacher:


    Code
    root@dm900:~# pgrep journalctl
    5862
    root@dm900:~# kill -9 5862
    root@dm900:~#


    das kann man aber dann auch in einem command killen
    kill -9 $(pgrep journalctl)

    Gruß Fred


    Die Dreambox ist tot, es lebe die Dreambox


    Einmal editiert, zuletzt von Fred Bogus Trumper ()

  • Hallo Swiss-MAD, danke für die Hilfe und die ausführlichen Beschreibungen. Ich werd jetzt nach und nach alle pugins einstellen und testen, insbesondere bei EPG, Auto-Timer und Elekro-Plugin. Wenn dabei etwas rauskommt werde ich es hier posten.


    Danke :winking_face:


  • Ich habe gesehen, das du per SSH auf die Box gehst. Ich mach das eigentlich immer mit Telnet. Ist ja alles nur lokal.
    Aber genau das macht den Unterschied.
    Wenn ich per Telnet drauf gehe, und das Log im Hintergrund starte, kann ich zwar mit exit auslogen, aber die Telnet Verbindung bleibt dann noch bestehen. Solange läuft auch das Log weiter.
    Sobald ich aber die Verbindung unterbreche, wird auch der "journalctl" Task gestoppt.


    Mache ich das hingegen mit SSH, wird mit exit nicht nur ausgelogt, sondern auch die Verbindung gleich beendet. Und der "journalctl" Task läuft weiter. :winking_face:


    Nur weshalb das so ist, weiss ich leider nicht. :face_with_rolling_eyes:
    Aber gut zu wissen. :grinning_squinting_face:

  • Swiss-MAD ich habe das nun nochmal getestet und du hast Recht :winking_face: Vielleicht wäre da eine Anfrage im DP Forum mal gerechtfertigt :winking_face:

  • Hallo.


    Das macht das & (und auch nohup)



    Code
    journalctl -f -u enigma2 > /tmp/enigma2.log &


    Wenn du willst das das log beim exit beendet wird einfach ohne eingeben


    Code
    journalctl -f -u enigma2 > /tmp/enigma2.log


    Wenn du den Command mit & beenden willst einfach die Prozess Liste aufrufen... den Task suchen und per kill beenden.



    Grüße

    -->
    openwrt + minicom + screen = 24/7 Bootlog

    5 Mal editiert, zuletzt von Schnello ()

  • Für was das &, disown oder nohup ist, ist schon klar. Und auch wie man den task stoppt.
    Im Moment geht es aber darum weshalb der Befehl obwohl er von der Shell gelöst ist unter SSH weiter läuft wie er soll, aber unter telnet stoppt sobald die Verbindung unterbrochen wird.

  • Ich glaube das liegt am protokol bzw. am daemon wie child processe gehandelt werden


    egal ob über telnet oder ssh (dropbear) - der Prozess journalctl -f -u enigma2 > /tmp/enigma2.log ist erstmal ein child des Protokolls über den der Prozess gestartet wird, sieht man schön mit pstree oder htop - kann nachinstalliert werden, wenn es am feed liegt


    wird die telnet session beendet, werden auch alle child prozesse von telnetd beendet - also auch journalctl
    wird dropbear beendet, wechselt journalctl den parent, d.h. journalctl ist dann ein child von /sbin/init - dem "Urprozess" (hat immer PID 1)


    Ich tippe das es am dropbear liegt. Mit (open)sshd anstatt dropbear in anderen Linux Distributionen wie debian werden childprozesse auch dann gekillt, wenn sie nur mit dem "&" am Ende im Hintergrund gestartet werden. Das bewirkt nur, dass die aktuelle ssh Session weiter verwendet werden kann und das CLI nicht durch den Prozess blokiert wird. Beim exit werden auch alle childprozessse von sshd beendet.


    Es könnte auch daran liegen, dass dropbear wie im OE2.0 über den xinetd superserver gestartet wird, während telnetd im Gegensatz zu OE2.0 im DreamOS einen eigenen Daemon verfügt (also nicht über xinetd gestartet wird). Aber da müsste mich erst einlesen.


    Wenn man also möchte, dass der Prozess im OE2.5 auch nach dem Verlassen des CLI in jeden Fall weiterläuft, sollte man den Prozess mit nohup oder screen starten


    nohup journalctl -f -u enigma2 > /tmp/enigma2.log &


    Wenn der Prozess so in einer telnet session gestartet wird, läuft er auch nach Verlassen der session weiter und der Prozess wird ein child von /sbin/init - d.h. es wird kein SIGTERM oder andere Signale beim Beenden der Session an den Prozess gesendet, der mit nohup gestartet wurde


    Wenn man möchte, dass der Prozess in jedem Fall beim Verlassen der Sessin beendet wird, lässt man das "nohup" am Anfang und das "&" am Ende weg. Das CLI wird dann duch den Prozess blokiert und der Prozess kann mit [Strg]+[C] oder [Strg]+[D] beendet werden. Man muss dann eine weitere Session starten, wenn man noch etwas anderes gleichzeitig über die shell machen möchte.


    so ein ähnliches Thema hatten wir schon mal, aber ich finde den Threat leider nicht mehr



    wie bereits geschrieben kann man diesen speziellen prozess dann mit killall über den Prozessnamen beenden (beendet alle Prozesse mit diesem Namen)
    killall -15 journalctrl beendet den Prozess (sauber)
    killall -9 journalctrl bricht den Prozess ab

    Gruß Fred


    Die Dreambox ist tot, es lebe die Dreambox


    4 Mal editiert, zuletzt von Fred Bogus Trumper ()

  • Hallo, ich hoffe hier liest noch jemand. Sorry das ich länger nicht geantwortet habe.


    Gersten Abend ist die Box zweimal während des normalen Fernsehprogramms abgestürzt der Ton lief noch das Bild war eingefroren.
    Der Zugriff über SSH war nicht möglich, die Fernbedienung reagierte nicht. Es half nur hart ausschalten.
    Nach dem Hochfahren startete der Timer der noch lief automatisch wieder. Nun zu den Fragen.


    Müsste ich nicht das logging auf die HDD schreiben "journalctl -f -u enigma2 > /tmp/enigma2.log" weil in tmp ists ja dann weg?


    Welche Log-Dateien sind denn noch sinnvoll sich anzuschauen?


    Besten Dank schon mal

  • Dazu gibt es mittlerweile ein größeres Thema bei DMM direkt. Hier wirst Du geholfen, sowohl Ilde Tod, als auch im Betrieb Bild friert ein während Ton weiter läuft: http://dreambox.de/board/index…-im-standby-ein/&pageNo=3