kleine Verbessungung für das init Skript

  • Frohes neues euch allen :]


    Ich habe es öfteren mal abstürze im VDR und da ist mir eine kleine Verbesserung für /etc/init/vdr.conf eingefallen:


    Code
    # backup last logfile
    if [ -f /tmp/vdr.log ]; then
       cp /tmp/vdr.log /tmp/vdr.log.0
    fi


    wäre super wenn man das einbauen könnte.


    Ich habe aber auch schon herausgefunden, dass man über /etc/defaults/vdr den vdr-dbg als Daemon setzten kann. Werde mich nochmal melden wenn ich die Ursache gefunden habe.

  • Das kann man noch einwenig ausbauen.


    Vor dem VDR Start
    ---
    corename=\$(date \"+%s\")
    echo "/tmp/%e-\$corename.core" > /proc/sys/kernel/core_pattern
    ---


    und nach dem Ende des VDR
    ---
    if [ -e /tmp/vdr-\$corename.core ]; then
    gdb -batch -x /etc/gdb/backtrace $DAEMON /tmp/vdr-\$corename.core > /var/log/vdr/backtrace.txt
    tar -cjf /var/log/vdr/\$(date "+%Y-%m-%d-%H-%M-%S").tar.bz2 --directory=/var/log/vdr/ backtrace.txt vdr.log
    rm /var/log/vdr/backtrace.txt
    rm /tmp/\vdr-\$corename.core
    fi
    ---


    Das triggert alle Fälle indem der VDR mit nem Coredump abgestürzt ist. Für Exitcodes ungleich 0 oder 1 ohne Coredump kann man das Logfile natürlich auch nach dem selben Muster wegkopieren.
    Dann hat man die Infos für alle Abstürze (unabhängig von logrotate) wegesichert.




    BTW: Das was du machst ist ja einfach ein manuelles Logrotate, das kann man besser gleich logrotate überlassen. Ensprechend konfiguriert reicht es einfahc vor jedem Start logrotate aufzurufen. Dann hat man für jeden VDR lauf ein eigenes Logfile und kann die letzten 20 Aufheben.


    cu

  • das mit dem coredump ist doch schon drin wenn man vdr-dbg als daemon setzt.


    EDIT.: ok der untere teil aber noch nicht ;) aber das geht glaub ich nicht mehr an der stelle (nach dem EXEC)



    Ich bin dem Problem aber nun mal auf der spur:

    Code
    Jan  1 19:33:14 vdr vdr: [12087] dbus2vdr: new message, object l#003#001#001#025#001, interface #004#001s, member or.AccessDenied
    Jan  1 19:33:14 vdr kernel: [19816.436403] vdr-dbg[12087]: segfault at 65642f68 ip 00007fe68dba050b sp 00007fe67b4d3ce8 error 4 in libdbus-1.so.3.5.4[7fe68db79000+42000]


    liegt wohl am vdr-plugin-dbus2vdr paket.


    EDIT2: ok,ich sehe gerade das alles (auch das logfile von vdr) in /var/log/vdr/ landet. Somit braucht die "verbesserung" gar nicht.

  • das mit dem coredump ist doch schon drin wenn man vdr-dbg als daemon setzt.


    Ich meinte als Erweiterung des Init Scriptes zum täglichen Betrieb. Wenn er mal im normalen Betrieb anstürzt möchte man am nächsten Tag (wenn man mal Zeit dafür hat) evtl. einfach mal wissen warum er gestern abgestürzt ist.


    Ich habe mit dieser Erweiterung jedenfalls gute Erfahrungen gemacht. Weil das Log alleine hilft ja meist nichts.


    cu

  • Ein backtrace ohne Debugsymbole ist halt nur wie Bleigiessen, sprich mehr wie Raten. Wer Probleme mit Abstürzen hat kann das ja auch mal eben nach installieren :) Was der vdr auf stdout ausspuckt wird rüberkopiert , siehe vdr-exit-other upstart job. :)

    VDR User: 87 - LaScala LC14B - LG/Phillipps 6,4" VGA Display | Asrock H61/U3S3 | G630T | 1x 16GB Mobi Mtron 3035 1x WD 750GB 2,5" |1x L4m DVB-S2 Version 5.4

  • Ein backtrace ohne Debugsymbole ist halt nur wie Bleigiessen, sprich mehr wie Raten.


    Jup, aber ohne Debugsymbole der Plugins helfen die im VDR auch nicht sonderlich ;)


    Eigentlich gibt es da ne Super Möglichkeit, man kann automatisch neben den gestrippten Paketen auch zusätzlich Pakete erstellen lassen die nur die dazugehörigen Debugsymbole enthalten.
    Dann installiert man ganz normal den gestrippten VDR und die gestrippten Plugins (so wie jetzt auch). Und dann installiert man die Debugsymbole (/usr/lib/debug/...) für VDR und Plugins dazu (Die 80 MB hat jeder noch über). Und dann hat man nen Backtrace mit allen was dazugehört ohne das man beim Abstürz erst anfangen muss was zu installieren und den Absturz zu wiederholen.



    Aber jeder wie er will, ich bin halt mit dem Logging so wie ich es habe glücklich. Wenn bei mir was schief läuft muss ich hier nicht 20 Km Log Posten und die Leute (die Lust haben sich da durchzuwühlen) raten lassen ;)


    Wer Probleme mit Abstürzen hat kann das ja auch mal eben nach installieren :)


    Aber leider sind die Abstürze meist sehr schlecht programiert, die kommen nämlich immer ganz unerwartet und nicht wie der Programierer das vorgesehen hat ;)


    cu

  • ich hab den absturz schon wieder gehabt... allerdings wird der backtrace nicht im logfile erzeugt. gdb ist allerdings installiert


    Die Stelle wo der Backtrace im logfile stehen sollte ist einfach leer... ?(


    hab jetzt mal das rm zum löschen des coredumps auskommentiert, damit ich es manuell bekommen kann.

  • ok, es wird anscheinend gar kein coredump erstellt? aber wieso? Der Benutzer vdr hat rechte auf den Ordner


    Wenn der VDR als User läuft braucht er nen Kommandozeilenparameter ("--userdump"). Ferner brauchts "ulimit -c unlimited".


    cu

  • ist im standard-init skript mit drin:


    Code
    # enable debug measures 
    if [ "$(basename $DAEMON)" = "vdr-dbg" ]; then 
       ulimit -c unlimited
       OPTIONS="$OPTIONS --userdump"
       echo "/var/log/vdr/core.%p" > /proc/sys/kernel/core_pattern
    fi


    wie man mit "ps aux|grep userdump" sieht läuft vdr auch mit dem parameter


    trotzdem kommt er nicht da raus... evtl funzt das mit dem core_pattern nicht?

  • Evtl. gibts einfach kein Coredump? Was sagt denn sdterr? Bei mir kommt da immer "Segmentation fault (core dumped) "


    Rechte fürs Verzeichnis stimmen sicher? Evtl. mal mit /tmp testen.


    cu

  • es kommt normal folgende Meldung im Logfile:


    Zitat

    Jan 2 04:00:39 vdr vdr-crash: vdr exit with exit status 1 . Restarting


    ok.. anscheinend crasht er aus verschiedenen ursachen:


    Zitat

    Jan 1 19:33:15 vdr vdr-crash: vdr exit with signal SEGV . Restarting


    das war wohl das eine mal als er auch die Meldung zu libdbus-1.so raus gehauen hat... allerdings startet er in letzter zeit einfach nur neu ohne SEGV


    Ich werde das nochmal beobachten...

  • Der Exit mit exit status 1 ist das emergency exit des VDR , das heisst der Grund dafür steht zB im Syslog. Da es ein geordnetes Beenden des VDR ist, gibt es natürlich kein Coredump :)

    VDR User: 87 - LaScala LC14B - LG/Phillipps 6,4" VGA Display | Asrock H61/U3S3 | G630T | 1x 16GB Mobi Mtron 3035 1x WD 750GB 2,5" |1x L4m DVB-S2 Version 5.4

  • sehr merkwürdig... es kommt genau alle 30 minuten vor:


    Im logfile steht aber kein Grund wieso vdr abstürzt:


  • Im logfile steht aber kein Grund wieso vdr abstürzt:


    Es stürzt ja nicht ab, er beendet sich geordnet.


    Hast du mal den Notausstig abgeschaltet? Sind alle Antenneneingänge belegt? Mal das Loglevel hochdrehen!


    cu

  • ok, hab mal das quite aus grub herausgenommen und den vdr neu starten, somit sollte das loglevel wieder höher sein


    Code
    # reduce verbosity if quiet is set in grub
    if [ "quiet" = "n" ]; then 
       OPTIONS="$OPTIONS -l 3"
    fi


    Habe nur eine DVB-Karte drinnen und die ist natürlich angeschlossen ;)


    Notausstieg? Wie Wo Was?

  • Notausstieg? Wie Wo Was?


    Irgendwo im VDR Setup. Eigentlich sollte der nur dafür da sein das ein fehlerhafter Empfang bei laufenenden Aufnahmen einen VDR Neustart auslöst. Aber irgendwie greift der auch manchmal ohne laufende Aufnahmen.


    Was sagt denn femon bezüglich BER? Mal längere Zeit beobachten.


    cu

  • Der VDR Watchdog ist doch Teil des VDR von Anbeginn der Zeit - es wundert/erschreckt mich schon wenn jemand der seit 2003 (8Jahre) dabei ist, das nicht kennt. Irgendeinen Grund wirds schon haben - mal das Log abwarten.

    VDR User: 87 - LaScala LC14B - LG/Phillipps 6,4" VGA Display | Asrock H61/U3S3 | G630T | 1x 16GB Mobi Mtron 3035 1x WD 750GB 2,5" |1x L4m DVB-S2 Version 5.4

  • Der VDR Watchdog ist doch Teil des VDR von Anbeginn der Zeit - es wundert/erschreckt mich schon wenn jemand der seit 2003 (8Jahre) dabei ist, das nicht kennt. Irgendeinen Grund wirds schon haben - mal das Log abwarten.


    Verzeih mir.. hatte auch ne Pause von über 3 Jahren - da iss nimmer alles so frisch und vorallem hat sich auch einiges geändert ;D



    ok, hab mal das quite aus grub herausgenommen und den vdr neu starten, somit sollte das loglevel wieder höher sein

    Code
    # reduce verbosity if quiet is set in grub
    if [ "quiet" = "n" ]; then 
       OPTIONS="$OPTIONS -l 3"
    fi


    Hab gerade gesehen, dass Level 3 schon das höchste ist.. wenn man vdr --help aufruft kommt zwar, dass es bis 7 geht. Aber das ist wohl nimmer aktuell, denn vdr startet so nimmer und meldet dass der Loglevel ungültig ist... Aber trotzdem, das ist eine Stelle im Init-Skript was man wohl korrigieren sollte, da eine Reduzierung < 3 wäre (3 ist allerdings auch Default von VDR) - irgendwie stimmt glaub ich auch die Bedingung nicht wirklich..?!


    Zu meinem Absturzproblem sagt dass allerdings dann auch nicht mehr aus (loglevel war ja dann schon immer "hoch"). Aber ich vermute wirklich, dass es am Signal liegt... ich habe zwar keinen der Sender welche momentan Probleme habe in Live Ansicht und auch keine Aufnahme darauf. Aber jedes mal vor dem Absturz wird der EPG Scan aufgeführt.. danach kommt evtl noch ein Transponserscan... dann "rutscht" er da sicher über die fehlerhaften Kanäle rüber.


    Ich werde die Dose aber voraussichtlich heute noch Tauschen und dann nochmal nachsehen...

  • Hab gerade gesehen, dass Level 3 schon das höchste ist.. wenn man vdr --help aufruft kommt zwar, dass es bis 7 geht. Aber das ist wohl nimmer aktuell, denn vdr startet so nimmer und meldet dass der Loglevel ungültig ist...


    Code
    -l level, --log=level
                  Set  logging  to  level.   0 = no  logging,  1 = errors only, 2 = errors and info, 3 = errors, info and
                  debug.  The default logging level is 3.  If logging should be done to LOG_LOCALn instead  of  LOG_USER,
                  add '.n' to LEVEL, as in 3.7 (n=0..7).


    Das nach dem Punkt was bis 7 geht ist die "Zieladresse" (also die angabe wer die Lognachrichten erhalten soll) und nicht das Loglevel.


    Aber jedes mal vor dem Absturz wird der EPG Scan aufgeführt.. danach kommt evtl noch ein Transponserscan... dann "rutscht" er da sicher über die fehlerhaften Kanäle rüber.


    Jup, fehlerhaften Enpfang mag der VDR nicht. Und auch die Treiber mögen sowas nicht. Gerade in dieser Ecke mag ich den VDR und Linux überhaupt nicht. Kaum gibts nen unvorhergesehendes Bit schon laufen die Buffer wild über und der VDR bleibt unbeendbar im I/O hängen und man muss den Netzstecker ziehen ;) Die nächste Anschaffung wird nen Hardwarewatchdog.


    Aber so schlimm ist es ja bei dir nicht (bei mir auch nicht, nur ca. 1x im Monat bleibt er so hängen), Notausstig deaktivieren sollte da helfen, und die Streamanalyse von femon kann man auch gerne abschalten.


    cu

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!