Träge Reaktionen und unerklärliche Neustarts bei der DM800se

Wir haben aktuell ein Problem mit dem Board und arbeiten an der Lösung...

    Danke Euch für die Beiträge. Ich nutze Teletext nie und dennoch kam es zu der Situation. Keine Ahnung, was das verursacht. Es ging ja nun auch einige Tage gut. Ich kann ja mal das Caching deaktivieren, aber irgendwie ist das für mich nur ein Workaround, da es ja seit vielen Jahren problemfrei lief. Auch per cron Job den cache Daemon killen, kann ich machen, aber das ist überspitzt formuliert wie die Box auszulassen, damit es keine Probleme gibt. Nicht wirklich eine Lösung.


    Sieht bei Euch die "ps" Ausgabe des dbttcd denn auch so "bröselig" aus wie das bei mir oben war?

    Wie gesagt ist es vermutlich ein Problem des Caching. Dafür musst du den Teletext ja garnicht öffnen :winking_face:


    Meine 800se ist nur noch sporadisch an. Da kommt es garnicht zu dem Problem. Evtl. kommt es aber auch nicht zum Problem, weil ich andere Satelliten/Sender in meinen Bouquets habe?
    Ich könnte mir durchaus vorstellen, dass es da ein Leak gibt, das bei gewissen vom Sender gesendeten Daten auftritt.


    Kann man den dbttcd Deamon irgendwie debuggen? einen logging mode gibt es ja.

    so long
    m0rphU



    :aufsmaul: Kein Support per PN! :aufsmaul:

    Zitat

    Original von m0rphU
    Ich könnte mir durchaus vorstellen, dass es da ein Leak gibt, das bei gewissen vom Sender gesendeten Daten auftritt.


    Ja m0rphU, sowas könnte ich mir auch gut vorstellen, denn das Problem tauchte nun wahrlich eine Weile nicht auf und auf meiner 500HD ist es noch nie gewesen, aber da schaue ich auch weit weniger fern, zappe nicht so viel, mache keine Aufnahmen und vor allem wird die 500 einmal täglich (per Elektro Plugin) runtergefahren. Meine 8000 läuft dagegen einfach durch...

    das Problem scheint es ab enigma2 um 20150528 zu geben, jedenfalls berichtete ein NN² User nach dem update auf v4.0.13, dass der htop MEM Wert für dbttcd auf 35% hochging und die Box immer träger wurde. Das "Puffern im Hintergrund" deaktivieren hat das Problem behoben


    Ich habe hier zwei SE V1 mit enigma2 Stand 20140314 und 20150105 (never change a running system) die 24/7 durchlaufen, der htop MEM Wert für dbttcd liegen bei ~2,7%, die cpu load 0% und die Boxen sind wg. dbttcd noch nie abgekackt ...



    Ich ein wenig auf der Box gestöbert, es gibt auch ein init script für dbttcd. dbttcd besser so per cron "resetten"


    Code
    0 4 * * * /etc/init.d/dbttcd restart



    m0rphU
    debug mode:


    debuging in den Teletexteinstellungen aktivieren und die Zeile 9 im init script wie folgt anpassen:

    Code
    root@dm800se:~# grep -n "wdog -S -b" /etc/init.d/dbttcd
9:    start-stop-daemon -q -p /var/run/dbttcd.pid -x /usr/bin/wdog -S -b -m -- -d dbttcd -l f -v 3 -f
root@dm800se:~#


    danach dbttcd neu starten

    Code
    /etc/init.d/dbttcd restart


    oder vielleicht besser die Box neu starten


    die option -l f logt nach /tmp/dbttcd.log (Deamon) und /tmp/dbttcp.log (Teletext)
    ob verbose level 1, 2, oder 3 müsste man testen oder bei DMM bzw. dem Entwickler nachfragen ....


    Wenn man das init script nicht anpasst und nur debuging in den Einstellung aktiviert, wird nur nach/tmp/dbttcp.log geschrieben



    \\Nachtrag
    auf meinen beiden SE ist auch ein 1GB SWAP Partiton auf USB aktiv

    Gruß Fred


    Die Dreambox ist tot, es lebe die Dreambox


    3 Mal editiert, zuletzt von Fred Bogus Trumper ()

    Danke Fred für die detaillierten Infos und Ideen. Werde ich darauf zurückkommen, wenn das Problem wieder da ist. Aktuell ist alles ganz "flauschig". "dbttcd" läuft, kaum CPU Last und Speicher auch soweit ok. Was ich nur nicht verstehe, warum bei der "ps" Ausgabe beim dbttcd immer so ein Brösel steht, bei "top" aber alles normal ausschaut:


    Code
    24030 root      20   0 43852 4904  360 S    1  3.3   2:28.90 dbttcd


# ps uax|grep 24030|grep -v grep
root     24030  0.1  3.3  27468  5084 ?        Ssl  Sep28   2:32 ????????????G

    die "Brösel" hab' ich nicht ...


    allerdings müsste dbttcd zwei mal auftauchen, einmal im wdog und als child


    Code
    root@dm800se:~# top -n 1|grep dbttcd
  530 root      20   0 41368 4768 1060 S    2  3.5   3:41.11 dbttcd
root@dm800se:~# ps uxa|grep 530|grep -v grep
root       530  1.7  3.5  24984  4768 ?        Ssl  17:40   3:41 dbttcd -f
root@dm800se:~#


    allerdings ist dbttcd ein child von wdog und dbttcd selbst hat auch zwei childs (lt. htop)

    Code
    529 root       26   6  1748   396   332 S  0.0  0.3  0:00.00 `- /usr/bin/wdog -d dbttcd -f
  530 root       20   0 41368  4768  1060 S  2.0  3.5  3:50.93 |  `- dbttcd -f
  569 root       20   0 41368  4768  1060 S  2.0  3.5  3:50.53 |     `- dbttcd -f
  568 root       20   0 41368  4768  1060 S  0.0  3.5  0:00.00 |     `- dbttcd -f


    ich glaub fast, dass da in der plugin.py was geändert wurde, ich mach mal ein diff ...



    \\Edit
    an der plugin.py wurde mit dem letzten update nichts geändert, da muss woanders der Hund begraben sein

    Code
    root@dm800se:~# diff /usr/lib/enigma2/python/Plugins/Extensions/TeleText/plugin.py /tmp/Teletext_dmm-exp-feed/usr/lib/enigma2/python/Plugins/Extensions/TeleText/plugin.py
root@dm800se:~#


    dbttcd ist auch die selbe version: 1.6


    __QT__
    swap aktiv?

    Gruß Fred


    Die Dreambox ist tot, es lebe die Dreambox


    Einmal editiert, zuletzt von Fred Bogus Trumper ()

    __QT__


    tausch' mal testweise /usr/bin/dbttcd ...


    das tar.gz nach /tmp


    /etc/init.d/dbttcd stop
    mv /usr/bin/dbttcd /usr/bin/dbttcd.ori
    tar vxzf /tmp/dbttcd.tar.gz -C /
    /etc/init.d/dbttcd start


    wenn es nichts bringt, kannst du ja das originale binary wieder herstellten

    Ja, Fred, hab eine 256MB SWAP Partition auf einer eingebauten SSD Platte:


    Code
    # cat /proc/swaps
Filename                                Type            Size    Used    Priority
/dev/sdb1                               partition       265036  17376   -1
# free
             total       used       free     shared    buffers     cached
Mem:        149552     143688       5864          0        128      18208
-/+ buffers/cache:     125352      24200
Swap:       265036      17376     247660


    So, nun mal gebootet und nun hab ich auch den wdog und dbttcd PIDs ganz "normal":


    Code
    # ps uax|grep dbttcd |grep -v grep
root       706  0.0  0.1   1748   292 ?        Ss   21:35   0:00 /usr/bin/wdog -d dbttcd -f
root       707  0.9  1.1  22764  1772 ?        Ssl  21:35   0:02 dbttcd -f


    Das mit dem wdog war vorm Reboot auf jeden Fall nicht so zu sehen.

    Ich melde mich auch mal wieder zu Wort, da das Problem bei mir die Tage auch wieder auftrat und auch da dbttcd in den Prozessen weit oben auftauchte. Demnach könnte das tatsächlich des Rätsels Lösung sein, auch das angegebene Update-Datum Ende Mai könnte hinkommen, allerdings ist das was hier in den letzten Beiträgen steht für mich noch nicht ganz durchsichtlich - was Kommandos usw. betrifft bin ich nämlich nach wie vor ziemlich Grün hinter den Ohren. :winking_face:


    Cron ist wenn ich das richtig verstanden habe eine Funktion, die bestimmte Scripte immer zur gleichen Uhrzeit ausführt. Wie genau lege ich den nun an, damit der Teletext-Cache jede Nacht geleert wird? Reicht da einfach via Telnet auf die Box zu gehen und dann


    Code
    0 4 * * * /etc/init.d/dbttcd restart


    einzugeben oder muss man da noch mehr eingeben, damit die Box versteht, dass sie das Ganze jede Nacht um 4 machen soll?

    im GP3 gibt es cronmanger - bin aber nicht sicher ober der lose comands ohne script mag (früher mochte er das nicht). Sonst den restart Befehl in ein Script packen und per cronmanger hinzufügen - oder das das DMM busybox cron verwenden. Aber das ist widerum "werkseitig" seit OE2.0 von DMM deaktiviert, dass man erst einmalig für den boot aktiveren muss und dann den cronjob mit crontab -e hinzufügen (dabei wird per default der Editor vi gestartet - was nicht jedermans Sache ist) und dann cron neu starten - aber das muss man alles in der Konsole machen



    wenn du kein GP3 nutzt: diesen cronjob zu busybox-cron (ohne vi) quick'n dirty hinzufügen:


    busybox-cron für den start beiim bootup aktivieren:
    update-rc.d busybox-cron defaults


    den cronjob hinzufügen
    echo "0 4 * * * /etc/init.d/dbttcd restart" > /etc/cron/crontabs/root


    und cron starten
    /etc/init.d/busybox-cron start


    oder Box neu starten


    das ist aber wirklich quick'n dirty und nur dann zu machen, wenn du cron bisher nicht nutzt. Das ist nicht unbedingt Linux konform - aber bevor ich hier crontab und vi erörtere ...


    wie man crontab in der console nutzt hilft auch die Boardsuche oder google weiter


    wenn du GP3 nutzt, hilft dir sicher die Boardsuche oder ein GP3 User weiter

    Gruß Fred


    Die Dreambox ist tot, es lebe die Dreambox


    4 Mal editiert, zuletzt von Fred Bogus Trumper ()

    weil das mit dem quick'n dirty crontab so ne Sache ist, habe ich als Alternative ein kleines System Plugin gebaut - nur als workaround, also auch keine Lösung


    wenn die Box träger wird, nach Installation und Enigma2 Neustart das Plugins über MENU - System - Einstellungen - "dbttcd restart" den Dreambox Teletext Cache Daemon neu starten

    Hab mir die Zeile


    Code
    /etc/init.d/dbttcd restart


    jetzt mal mit PSPad in eine sh-Datei geschrieben und die dann über Cron im Bluepanel als wiederholendes Ereignis jede Nacht um 4 gesetzt. Das sollte doch so jetzt funktionieren, oder?

    Zitat

    Original von Fred Bogus Trumper
    ja, das funktioniert auch.


    die shebang steht aber auch in dem script - oder?


    Bash
    #!/bin/sh


/etc/init.d/dbttcd restart


exit 0


    Nein, bisher hatte ich da nur die eine Zeile drinstehen.
    Hab es jetzt aber nach deinem Hinweis auch eingefügt. Was passiert denn wenn das nicht drinsteht? Bisher hab ich nämlich nichts feststellen können.

    das Script wird gar nicht ausgeführt, weil das System nicht weiß, mit welchem Programm es ausgeführt werden soll


    du musst auch noch das Script ausführbar machen, sonst funktioniert es auch nicht


    chmod 755 /pfad/zum/Script/scriptname.sh


    also z.B.. chmod /usr/script/dbttcd_restart.sh


    je nachdem wo dein Script liegt bzw. wie du es genannt hast



    Edit:
    um sicher zu gehen: konvertiere das script auch ins UNIX Format, wenn du eine neue Datei am Windows PC erstellst, kann es gut sein, dass es im DOS Format gespeichert wurde, dann klappt das mit dem Neustart auch nicht ,,,



    dos2unix /pfad/zum/Script/scriptname.sh


    danach vielleicht mal manuell testen

    Gruß Fred


    Die Dreambox ist tot, es lebe die Dreambox


    Einmal editiert, zuletzt von Fred Bogus Trumper ()

    Die Rechte hatte ich selbst schon geändert, hab das Ganze jetzt spaßeshalber aber wie du sagst selbst mal getestet. Das Script scheint wie gewünscht zu laufen, Telnet gab beim Ausführen erst "Stopping dbttcd" und dann "Starting dbttcd" aus. Dann hoffe ich jetzt mal, dass die Hänger damit auch Geschichte sind. :)

    wenn der cronjob richtig angelegt ist, sollte das dann funktionieren


    du könntest noch diese Zeile vor dem exit in das script machen, um zu kontrollieren ob das script ausgeführt wird

    Code
    echo $(date +%b" "%d" "%H:%M:%S) $(hostname) dbttcd restarted by cron >> /tmp/dbttcd_restart.log


    dann siehst du in /tmp/dbttcd_restart.log ob der das Script ausgeführt wurde

    Code
    root@dm800se:~# cat /tmp/dbttcd_restart.log 
Oct 01 04:00:01 dm800se dbttcd restarted by cron
root@dm800se:~#


    alternativ sieht man es auch in /var/log/messages


    grep cron /var/log/messages

    Gruß Fred


    Die Dreambox ist tot, es lebe die Dreambox


    Einmal editiert, zuletzt von Fred Bogus Trumper ()