Auf Syslog-Eintrag reagieren

  • Ich habe mit meiner Cine S2 V5.5 immer mal wieder das Problem:


    Code
    ngene: Command timeout cmd=04 prev=04
    Dec 23 20:22:38 htpc kernel: [28708.088044] host_to_ngene (c000): 0d d3 f6 e9 8f 7b d3 7b
    Dec 23 20:22:38 htpc kernel: [28708.088047] ngene_to_host (c100): 01 fc 7e e7 f7 93 2d 2b
    Dec 23 20:22:38 htpc kernel: [28708.088050] dev->hosttongene (ffff880084cfc000): 04 04 d0 f1 2b fb 00 01
    Dec 23 20:22:38 htpc kernel: [28708.088052] dev->ngenetohost (ffff880084cfc100): 00 00 00 00 00 00 00 00


    Wenn das passiert reicht es den VDR zu beenden, den ngene Treiber neu zu laden und den VDR wieder zu starten. Wenn ich selber vorm TV sitze mache ich das per lircrc-Script. Manchmal tritt das Problem aber leider auch auf, wenn der VDR automatisch für eine Aufnahme gestartet wurde. Wie kann ich in dem Fall mein "Repair-Script" ausführen? Gibt es eine Möglichkeit auf die Einträge im Syslog zu reagieren? Per Cronjob? Hat jemand genau das zufällig schonmal gemacht und kann mir seinen Cronjob zur Verfügung stellen? Würde mich sehr freuen :)

  • Gibt es eine Möglichkeit auf die Einträge im Syslog zu reagieren?


    Schau dir mal die Doku zu deinem Syslog Daemon an. Z.B. rsyslog: http://rsyslog.com/doc/rsyslog_conf_actions.html (Shell Execute)


    Kommentare dazu kaputte Hardware/Treiber zu nutzen spare ich mir jetzt ;)


    cu

  • Danke, schau ich mir mal an.

    Kommentare dazu kaputte Hardware/Treiber zu nutzen spare ich mir jetzt ;)

    Was soll ich machen? Am Treiber kann ich nichts ändern und unproblematischere (Budget DVBS2-) TV Karten scheint es ja auch eher nicht zu geben. Bin ja schon froh, dass sie ansonsten zuverlässig funktioniert...

  • BTW: Das Dynamite Plugin bietet die Möglichkeit dem VDR zur Laufzeit ein DVB Device zu entziehen und (nach dem Treiberneustart) wieder anzubinden, damit könntest du dir den VDR Neustart sparen.


    Was soll ich machen? Am Treiber kann ich nichts ändern und unproblematischere (Budget DVBS2-) TV Karten scheint es ja auch eher nicht zu geben. Bin ja schon froh, dass sie ansonsten zuverlässig funktioniert...


    War auch nicht unbedingt ein Vorwurf an dich (bei DVB und Linux ist aktuell alles ziemlich müllig), nur ist sowas generell Bastelei und eigentlich nix womit man auf Dauer glücklich ist. Und ich fühlte mich gezungen das mal zu erwähnen ;)



    Keine Ahnung wo der Treiber für deine Karte herkommt (diese Situation ist auch aktuell ziemlich blöd bei Linux, wo es die Treiber gibt wissen nur Insider), aber es könnte mal lohnen neuere/ältere Versionen zu probieren oder zu schauen obs irgendwo nen Patch (es gibt viele Patches für Problemlösungen die es aus irgendwelchen Gründen nie bis in den Upstream schaffen) für dein Problem gibt.


    cu

  • So, mit rsyslog ein Script ausführen ist ja tatsächlich kein Problem. Leider wird das Script natürlich als syslog-User ausgeführt unter dem ich natürlich nichts darf. sudo (mit NOPASSWD für mein Script) scheint für syslog auch nicht zu funktionieren und wäre Sicherheitstechnisch wohl auch keine gute Idee ;)

    BTW: Das Dynamite Plugin bietet die Möglichkeit dem VDR zur Laufzeit ein DVB Device zu entziehen und (nach dem Treiberneustart) wieder anzubinden, damit könntest du dir den VDR Neustart sparen.

    Gute Idee. Werd ich mir auch mal anschauen. Ist aber nicht ganz so wichtig, der Fehler tritt ja immer nur direkt nach dem Boot bzw. nach dem Aufwachen aus dem Standby auf. Da ist ein VDR-Neustart schon ok.

    Stimmt schon. Ich benutze momentan die dkms-Version von yavdr die im Gegensatz zum Standard-Kerneltreiber (der auch das "command timeout" Problem hat) immerhin eine korrekte femon-Signalanzeige bietet.

  • So, mit rsyslog ein Script ausführen ist ja tatsächlich kein Problem. Leider wird das Script natürlich als syslog-User ausgeführt unter dem ich natürlich nichts darf.


    Das was du per Syslog aufrufst sollte eh nix tun ausser per "at now" (das ist dann vom Syslogprozess entkoppelt) das richtige Script zu starten. Jedenfalls wenn ich die Kommentare dort richtig lese.


    Gibts hier (at) auch Rechteprobleme dann würde ich ein kleines Stub Programm *) (Shell Script und setuid geht nicht) nutzen was per http://de.wikipedia.org/wiki/Setuid mit root Rechten gestartet wird und die Aktionen (ohne Auswertung irgendwelcher Kommandozeilenparameter, dann gibts hier auch keine Sicherheitsprobleme) ausführt.


    cu


    *) Das tuts schon

  • Ich habe mal einen Script-Daemon zur Mail-Log Auswertung geschrieben, das über einen FIFO-Puffer lief. Das ist eine recht elegante Methode, weil man sich nur um das kümmert was gerade geschrieben wurde, und nicht das ganze File Parsen muss.


    Erstmal braucht man einen FIFO-Puffer, das geht recht simpel mit:

    Code
    mkfifo /var/log/kern.fifo


    Diese Spezialdatei bleibt, muß also nur einmal angelegt werden. Als nächstes kümmert man sich um das füllen dieses Puffers. Ich nehme mal an du willst Kernal-Einträge. Dann erweitere die /etc/syslog.conf um die Zeile:

    Code
    kern.*    |/var/log/kern.fifo


    Danach den syslog-Daemon neu starten. Jetzt werden alle Kernal-Nachrichten in den Puffer kopiert und können ganz normal ausgelesen werden. Ich habe das damals mit einem Perl-Daemon gemacht. Hier mal das Grundgerüst dazu:


    Diese Methode hat fast keine CPU-Last und verliert auch keine Log-Lines wenn der Daemon mal wegen Fehlern abgebrochen wurde.

    Hardware: Point of View ION/ATOM330, 2GB, 160GB (Lokal), 2TB über NFS, Hauppauge Nova-T Stick (2040:7070), SoundGraph IMON (15c2:0036 VFD)
    System: Debian Squeeze, Kernel 3.1.2 (self build), Nvidia 285.05.09, lcdproc 0.5.5, lirc 0.9.0
    VDR: vdr 1.7.21 (etobi) + xvdr (git), xineliboutput, markad
    XBMC: opdenkamp PVR branch (git)

  • Danke für die Ideen :)
    Muss mal schauen was am Besten funktioniert.
    Spricht eigentlich was gegen ein tail -f auf Syslog? Also z.B. tail -n 1 -f /var/log/syslog | awk '$0 ~/ngene: Command timeout/ { system(sudo -i "/usr/bin/vdrrepair") }'

  • Spricht eigentlich was gegen ein tail -f auf Syslog?


    Ja, das ist Murks ;) rsyslog verarbeit und Matcht eh jede Syslog Nachricht, da bietet es sich an das rsyslog in bestimmten Fällen gleich die passenden Programme startet. Ein ständiges Pollen per "tail -f" ist da rein technsich sehr blödsinnig.


    Alles IMHO natürlich.


    cu

  • ok, ich habs nun per rsyslog, at und sudo hinbekommen. Das Script wird zwar drei mal nacheinander ausgeführt aber funktioniert jedenfalls.
    Bei den Tests um das Problem zu reproduzieren habe ich dann aber wohl vermutlich den eigentlichen Grund für den Fehler gefunden: Wenn der VDR irgendwie beim suspend hängt, kann der Treiber nicht entladen und nach dem Resume daher auch nicht neu geladen werden. Und genau in dem Fall treten die Fehler auf. Wenns der VDR ist kann ich den vorm Standby ja notfalls nochmal killen, aber was wenn es irgend etwas anderes ist? Reproduzieren kann ich das z.B. indem ich femon laufen lasse während ich in den Standby fahre.

Jetzt mitmachen!

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