Frage zu meinem Crashlog

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • wird schwierig, aus dem Log nach automatischem Neustart einen Fehler herauszulesen.
      Um den Fehler zu analysieren, musst du von "Schleife" auf "Datei" umstellen und dir das Logfile vor dem Neustart ansehen.
      Den aktuellen Log vor dem Neustart hast du derzeit sicherlich nicht mehr.

      Bei mir gab es auch immer mal Crash Logs mit 0 Byte, was auf fehlerhafte Netzwerkzugriffe zurückzuführen war.
      Hast du eventuell ein NAS als HDD Ersatz eingerichtet und die VTI.DB und/oder EPG.DB auf dem NAS?
      Ich meine bei mir mal irgendwann im Debug Log gelesen zu haben, dass durch den Zugriff auf die VTI.DB ein Absturz und Crash-Log mit 0 Byte entstanden ist.

      Seitdem ich beide Datenbanken auf der internen SSD abgelegt habe, ist bei mir Ruhe.

      Leg beide Dateien mal in den Flash.
      Rechtschreibfehler sind beabsichtigt, sie fördern ein genaueres Lesen
      Debug Log aktivieren Putty Telnet Screenshots erstellen
    • @Dieter59 : in deinem Debug-Log sehe ich öfters einen Fehler von Netatmo :

      Brainfuck-Quellcode

      1. 12:54:58.450 [e2-python] [Netatmo] start async update
      2. 12:54:58.451 [e2-python] [Netatmo] begin update
      3. 12:54:58.451 [e2-python] [Netatmo] token expire in 4860
      4. 12:54:58.804 [e2-python] --- [Netatmo] STACK TRACE ---
      5. 12:54:58.805 [e2-python] Traceback (most recent call last):
      6. 12:54:58.806 [e2-python] File "/usr/lib/enigma2/python/Plugins/Extensions/Netatmo/NetatmoCore.py", line 83, in getString
      7. 12:54:58.806 [e2-python] return unicode(self.data[key])
      8. 12:54:58.807 [e2-python] KeyError: 'country'
      9. 12:54:58.807 [e2-python] -----------------------------
      10. 12:54:58.927 [e2-python] [Netatmo] update took 0.475405931473 sec
      kann ich nicht deuten, da ich kein Netatmo habe ... aber vielleicht dem mal anchgehen, bzw. Netatmo deaktivieren ?
    • @hajeku123 hab zwar ein NAS, das dient allerdings nicht als hdd Ersatz und auch VTi.db und EPG.dat liegen im Flash. Ich stelle aber mal auf Datei, ist ja eigentlich auch klar, dass man mit dem Debug-Log NACH dem Absturz nicht viel sehen kann ;(

      @gordon55 ich deaktiviere das Netatmo Plugin mal, aber erst, nachdem ich wieder einen Crash mit ner orfentlichen Debug-Datei habe. Wenn‘s dann wirklich das Netatmo-Plugn sein sollte, müsste man das ja auch sehen.
    • Bei mir gibt es eine Datei EPG.DB und nicht EPG,dat,
      Kann auch sein, dass es diese Datenbank war, welche auf dem NAS zu Problemen geführt hatte...
      Ich meine, die kommt von EPGShare.
      Rechtschreibfehler sind beabsichtigt, sie fördern ein genaueres Lesen
      Debug Log aktivieren Putty Telnet Screenshots erstellen
    • jep, so auch mein Verständnis :
      • epg.dat : die gab es schon immer, wird auch z.B. von EPGRefresh aktualisiert, und auch beim Umschalten (EIT-EPG von SAT)
      • epg.db : die ist erst mit EPGShare vorhanden, also wohl die "Extra-Daten". Die ist auf meiner Solo² nicht vorhanden, da ich dort kein EPGShare installiert habe.
      auf der Uno4K hab ich beide Dateien im Flash liegen, also /etc/enigma2 ... und damit keine Probleme ^^
    • letzteres deutet eigentlich wieder darauf hin (und sowas war schon mal in einem anderen Thread), dass es ein Problem mit einem verbundenen Speichermdium gibt und durch log-schreiben jetzt die Speicherstelle 'offen gehalten wird' und dadurch das speichern problemlos läuft

      solltest mal das log untersuchen, wann und wohin denn nun wirklich etwas geschrieben wird, evtl wirst da fündig
      ============================================================================================
    • Hallo mal wieder,
      der @shadowrider hat mich noch auf eine Idee gebracht, @Dieter59 :
      • lt. deinem Debug nutzt du 4 NFS-Shares, eingebunden über den VTI-Freigabeassistenten per "autoFS" ... richtig ?
      • das Debuglog wird im VTI ja auf /media/hdd geschrieben ... "Festplattenersatz" hast du hoffentlich nicht aktiv, oder ?
      • wenn dem so ist ... nun ja, die Einstellungen für autoFS sind hier im VTI mMn. echt "suboptimal", das hatte ich schon mehrfach hier im Forum geschrieben ... ohne jegliche Reaktion :whistling: auch im aktuellen VTI 13.0.12-Image sind die ollen Timeouts drin.
      • die Datei "/etc/default/autofs" beinhaltet hier Timeouts, dass z.B. 5 sec (!!) nach einem Mount das device wieder abgehängt wird ... Standard bei autoFS unter Linux sind 10 min = 600 sec. !! steht auch in der Datei so drin, warum das bei VTI nur 5 sec sind, ist mir unbegreiflich.
      • bei deinen 4 autofs Mounts wirst du wohl sehr viele mounts/umounts im /var log/messages sehen ... ^^ , wenn du auf die Netzwerklaufwerke zugreifst, oder ?
        das würdest du auch in der Konsole sehen können, wenn du einfach "mount" eingibst, nachdem du auf ein Netzwerklaufwerk zugreifst ... bei mir sind die diese im Mount noch 5 min. zu sehen, bei dir wahrscheinlich nach 5 sec schon wieder weg :)
      • ich habe daher bei mir das VTI autofs gelöscht und bleibe bei meiner auto.network... OHNE VTI ^^
      • zudem habe ich die Timeouts angepasst in der "/etc/default/autofs"... sieht bei mir grad so aus ... und läuft :D
      hope it helps ...
      Dateien
      • autofs.txt

        (3,87 kB, 7 mal heruntergeladen, zuletzt: )
    • ich liebe es definitiv auch :thumbup:
      mit der Anmerkung, dass ich diese Änderung an der autofs-config bereits seit ca. 3 Jahren aktiviert habe ... muss ich halt bei jedem Image-Update wieder nachziehen :whistling: ... passiert ja nicht all zu häufig, daher kann ich damit leben, dass die autofs-Timeouts im VTI mMn. "banane" sind.

      Hier im Falle von @Dieter59 kann ich mir jedoch vorstellen, dass es z.B. durch Abspielen von Filmen vom Netzlaufwerk, welches per autofs gemountet ist, durch die zahlreichen Mounts/Umounts evtl. zu Rucklern und auch "Hängern" kommen kann, müsste man aber fallweise genauer untersuchen.
      Ich kann jedenfalls ohne Probleme Filme von der NAS oder der anderen VU auf jeder VU bspielen und habe keine 0B-Crashes o.ä., jedenfalls nicht, seit ich die autofs-config konsequent nach jedem Image-Update nach ziehe .
    • ich gehe auch nicht davon aus, dass es bei jedem mit ähnlichen Problemen genau die gleiche Lösung ist - jedoch am Anfang steht eben das beobachten im log wie von mir angeraten (oder wie auch schon öfter angeraten und wenn man es denn kann, Schritte nachgehen was wann wo passiert - in dem Fall hier eben Daten schreiben/lesen)
      ============================================================================================
    • gordon55 schrieb:

      Hallo mal wieder,
      der @shadowrider hat mich noch auf eine Idee gebracht, @Dieter59 :
      • lt. deinem Debug nutzt du 4 NFS-Shares, eingebunden über den VTI-Freigabeassistenten per "autoFS" ... richtig ?
      • das Debuglog wird im VTI ja auf /media/hdd geschrieben ... "Festplattenersatz" hast du hoffentlich nicht aktiv, oder ?
      • wenn dem so ist ... nun ja, die Einstellungen für autoFS sind hier im VTI mMn. echt "suboptimal", das hatte ich schon mehrfach hier im Forum geschrieben ... ohne jegliche Reaktion :whistling: auch im aktuellen VTI 13.0.12-Image sind die ollen Timeouts drin.
      • die Datei "/etc/default/autofs" beinhaltet hier Timeouts, dass z.B. 5 sec (!!) nach einem Mount das device wieder abgehängt wird ... Standard bei autoFS unter Linux sind 10 min = 600 sec. !! steht auch in der Datei so drin, warum das bei VTI nur 5 sec sind, ist mir unbegreiflich.
      • bei deinen 4 autofs Mounts wirst du wohl sehr viele mounts/umounts im /var log/messages sehen ... ^^ , wenn du auf die Netzwerklaufwerke zugreifst, oder ?
        das würdest du auch in der Konsole sehen können, wenn du einfach "mount" eingibst, nachdem du auf ein Netzwerklaufwerk zugreifst ... bei mir sind die diese im Mount noch 5 min. zu sehen, bei dir wahrscheinlich nach 5 sec schon wieder weg :)
      • ich habe daher bei mir das VTI autofs gelöscht und bleibe bei meiner auto.network... OHNE VTI ^^
      • zudem habe ich die Timeouts angepasst in der "/etc/default/autofs"... sieht bei mir grad so aus ... und läuft :D
      hope it helps ...
      Zuerst mal ganz lieben Dank für die ausführliche Beschreibung!

      Ja, ich nutze autofs
      Ja, er schreibt /media/hdd und Festplattenersatz ist nicht aktiv
      ich habe mir die var/log/messages mal angeschaut, da sind etliche Fehlermeldungen drin mit denen ich aber nicht viel anfangen kann, vielleicht kann ein wissender da mal reinschauen?
      Ich hatte auch heute morgen um 10:55 einen 0 Byte Crash und den Debuglog, hänge ich hier auch mal an.


      das ist schon so lange her, dass ich gerade nicht weiß, was ich machen muss, um von autofs wieder auf auto.network umzuswitchen.

      Und den letzten Punkt habe ich nicht verstanden, wenn Du autonetwork verwendest, warum hast Du dann die timeouts in der autofs geändert?
      Dateien

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Dieter59 ()

    • Dieter59 schrieb:

      Ich habe äußerst selten einen Crash während des normalen Betriebs und da idR bei der Wiedergabe von Aufnahmen.
      @shadowrider : ich glaube auch, dass es keine "Universal-Lösungen" gibt, aber hier mal ein Zitat ausm Post 3 : "Wiedergabe von Aufnahmen"
      @Dieter59 : mein Vorschlag wäre hier zur weiteren Analyse :
      1. stelle den Debug auf Datei, OHNE Schleife. dann siehst du nach jedem Crash auch ohne crashlog noch was.
      2. bitte noch mal das "absolut genaue Scenario" schildern, wann die Box jetzt crasht ... letzte TastenDrücke, Funktionen, was läuft, etc.