Schnittmarken setzen

Zitat

Original von Thyor
Daher bleibt weiter ungeklärt:
Wie rette ich nun das Log über einen harten Reset, zwecks Fehleranalyse?

Gar nicht.

Zitat

Wo wir gerade beim "Log" sind, noch eine Zusatzfrage: Kann man bestimmte Logeinträge (Umgeschaltet auf Programm x, Bild xxx gegrabt, ...) wahlweise unterdrücken?

Nein.

Tom.

Hi,

mottobug, thyor:

habe mir soeben mal busybox angesehen. Wenn ich das richtig verstehe, werden diverse Kommandos ja emuliert. Kann man damit auf die fiktiven Verzeichnisse und Dateien zugreifen?
Meine Vorstellung wäre

tail -f /ramdisk/../../syslog > /error.log

Also im Prinzip das Abgreifen der Meldungen und Umleiten in eine echte Datei. Ist sowas denkbar oder lässt busybox einfach alles im Nirwana verschwinden?

D.

Zitat

Original von linuxfreund
Meine Vorstellung wäre
tail -f /ramdisk/../../syslog > /error.log
Also im Prinzip das Abgreifen der Meldungen und Umleiten in eine echte Datei. Ist sowas denkbar oder lässt busybox einfach alles im Nirwana verschwinden?

Der Syslog hat einen Ringbuffer. Nichts davon landet je auf der Festplatte. Es kann sein das man ihn auch anders Konfigurieren kann, wissen tue ich es nicht.

Man könnte sowas wie "logread > /messages" machen. Wäre aber Zweckfrei denn um das zu tun müsste das Kommando nach dem Absturz ausgeführt werden...

Tom.

Hi,

ich gehe auch nicht davon aus, dass irgendwas auf der HD landet. Ich dachte eher an das /proc-Filesystem - auch nicht wirklich existend, und doch mit einer Ausgabe versehen, die es ermöglicht, mit Standardprogrammen darauf zugreifen. Wenn die busybox-eigenen Tools derart umgeschrieben wurden, dass sie die busybox-Gegenbenheiten berücksichtigen, könnte es ja durchaus sein, dass man, wie von mir vorgeschlagen, mit tail auch auf eine fiktive syslog zugreifen kann. Da tail die Programmausgabe ja sofort an stdout weitergibt könnte man diese Ausgabe auch in eine echte Datei umleiten. So hätte man alle Meldungen bis zum Absturz.
Entscheidend allso nur: Kann man mit mit dem busybox-eigenen tail auf eine nur im Rinpuffer vorhandene Datei zugreifen?

D.

Zitat

Original von linuxfreund
Entscheidend allso nur: Kann man mit mit dem busybox-eigenen tail auf eine nur im Rinpuffer vorhandene Datei zugreifen?

Wie würde Cooper sagen, "rede ich Blech"?

NEIN! ES GEHT NICHT.

Ein Ringbuffer ist eine art FiLo (First in, Last out). Im Prinzip also nur eine Liste (Array) mit X Elementen. Kommt eine neue Meldung in diese Liste, fliegt die letzte Meldung raus. Es ist eine Datenstruktur im Speicher. Nix Datei, nix Tail, nada.

Tom.

Hallo,

bevor ich staunend zusammenbreche und (damit ;)) mottobug explodiert:

Im Klartext:

Durch jeden Neustart, unabhängig ob sauber oder mit Gewalt, geht der Inhalt des Logs (=Ringbuffer) verloren!?

Vorbei ist's mit Fehlersucherei ....

Zitat

Original von Thyor
Durch jeden Neustart, unabhängig ob sauber oder mit Gewalt, geht der Inhalt des Logs (=Ringbuffer) verloren!?

Du kannst ja anstatt deinem RAM ne FlashDisk einbauen. Dann bleibt der Speicherinhalt über den Neustart hinweg erhalten.

Viel Spaß,
Tom.

Hallo,

man kann doch das Log zur Fehlersuche retten!
Dazu ruft man syslogd statt mit der Ringbuffer-Option ( -C ) mit der Logfile-Option ( -O ) auf:

Zitat

Änderung in /etc/init.d/rcStart
# execute syslogd -C
execute syslogd -O /slog.txt

Die Logdatei (hier /slog.txt) wird auch nach einem reboot fortgeführt!

Nach einem ersten (unkundigen) Blick sieht es so aus, als wenn deutlich mehr drin stehen würde!? D.h. evtl. das standardmässig die ersten Meldungen schon während des Bootvorgang im Ringbuffer-Betrieb schon wieder überschrieben werden!

Jetzt kann der Fehler kommen!

Hallo,

hab jetzt über mehrere Tage die Logs laufen lassen, aber ...

mein VDR läuft derzeit weiterhin keine 24h durch!

Einen direkten Zusammenhang mit dem Auto-NoAd-Änderung ist aber nicht zu erkennen:

Mehrmals waren folgende Zeilen, die letzten Lebenszeichen:

Zitat

Dec 12 05:17:11 linvdr user.info vdr[111]: connect from 127.0.0.1, port 32787 - accepted
Dec 12 05:17:13 linvdr user.info vdr[111]: closing SVDRP connection

Jemand eine Idee?

Zitat

Original von Thyor
Jemand eine Idee?

Nein. Es sieht so aus als ob der Rechner einfach irgendwann einfriert. Vielleicht hast du glück und kannst irgendwann ein Muster erkennen. Auf Verdacht würde ich einfach mal die DVB Karte in einen anderen Slot stecken. Wenn das auch nicht hilft (ist ein Strohhalm), weis ich auch nicht...

Tom.

Zitat

Original von Thyor
Jemand eine Idee?

epgscan?

-- randy

Hallo,

mottobug:
Anderer Slot: Geht leider nicht! Der Scovery hat nur 2 Slots und ich habe ja zwei DVB-Karten! Interrupttechnisch ist alles sauber bis auf die Nexus. Dummerweise wird diesem Slot und der Onboard-Netzwerkkarte der gleiche Interrupt zugeordnet.
Frage an Hardware-Bastel-Freaks:
Das Mainboard des Scovery (= Scenix xS) hat ursprünglich 4 PCI-Slots
von denen jedoch nur die letzten beiden per Winkeladapter in die Senkrechte verlegt wurden!
Per BIOS kann man den Slots ja einen Interrupt zuordnen.
Leider müssen sich einige Slots diesen einen Interrupt aber (festverdrahtet!)
mit einer Onboard-Komponente (Netzwerkkarte, Sound, USB usw.) teilen.
Ist es wohl möglich die Interruptleitungen eines anderen Slots, der seinen Interrupt nicht teilen braucht,
per Freiluftverdrahtung und Leiterbahnunterbrechung an den Nexus-Slot zu ziehen?

randy:
Auch ne Möglichkeit!
Wie kann man es erkennen? -> Abstellen und abwarten?

Welche Nachteile bringt ein abgestellter EPG-Scan?

Zitat

Original von mottobug

Nein. Es sieht so aus als ob der Rechner einfach irgendwann einfriert. Vielleicht hast du glück und kannst irgendwann ein Muster erkennen. Auf Verdacht würde ich einfach mal die DVB Karte in einen anderen Slot stecken. Wenn das auch nicht hilft (ist ein Strohhalm), weis ich auch nicht...

Tom.

Sieht für mich aber so aus als ob das wirklich der gesharedte (nettes Denglish)
IRQ ist den das letzte Lebenszeichen ist ein "Netzwerkzugriff". Um das endgültig zu verifizieren, versuch doch mal ne Datei auf den Rechner zu kopieren! Wenn das System dabei einfriert has Du den schuldigen!!

Michael

Hallo mikeM,

hab mal eine große Datei auf den VDR kopiert und in der Zeit gleichzeitig wild rumgezappt:

Abgeschmirrt isser nicht, aber die TV-Wiedergabe war mehrfach schwer gestört! Konnte ihn nur mit dem Abspielen einer Aufzeichnung wieder beruhigen!

Werde mal die On-Board-Karte deaktivieren, aufs Netz verzichten und dann mal schon wie lange er dann noch "lebt!"

Das mit dem wilden rumzappen war eine gute Idee, ist nämlich in etwa das gleiche wie beim EPG-Scan! Wenns das war ist ja gut

Michael

Hallo,

knappe sechs Stunden hat er ohne Netzwerkkarte überlebt, dann blieb er hängen! Die Netzwerkkarte ist wohl ein Störfaktor, aber scheinbar nicht der Auslöser!

Also dann geht die Suche jetzt mal Richtung EPG-Scan!
Um den EPG-Scan abzustellen, ist doch der Scan-Zeitraum auf 0 zu stellen!?

Zwischenstand: Die Nacht hat er bereits ohne Absturz überstanden! Vermutlich ist damit der Übeltäter gefunden!

Ist eigentlich bekannt, warum der EPG-Scan so "tödlich" sein kann?
Wird der Scan per Script gestartet, so dass man die Aufrufe per Logger-Befehl kennzeichnen kann und ggf. abwandeln bzw. ersetzen könnte?

Hallo,

nachdem alle bekannten und unbekannten potentiell problemrelevanten Einstellungen deaktiviert wurden und die Kiste weiterhin abstürzte, habe ich mich zu einem noch radikaleren Test durchgerungen. Dazu habe ich den VDR von meinem so geliebten schnuckeligen Scovery in einen betagten Tower Scenic Pro M6 / PII 333 Mhz transplantiert. Der Scovery war doch mächtig "voll" geworden. Wärme- und Spannungstechnisch vermutlich am Limit oder bereits drüber!

Jedenfalls hat er die Nacht bereits gut überstanden!
...und ein eigener Interrupt ist auch schon drin!

Ergänzung:
Nach 36h "Dauerbetrieb" läuft die Kiste immer noch!

Daher kann ich wohl die "Autoschnittmarken"-Änderung, den EPG-Scan, die RAM-Disk für Videotext und die EPG-Zeitstellung für Unschuldig erklären, mich beruhigt zurücklehen und auf die 0.5er-Version freuen!