VDR lässt sich manchmal nicht killen

  • Hallo,


    Manchmal bleibt mein VDR extrem hängen, das witzige ist das dann gar nix mehr geht, pidof vdr bleibt hängen (und lässt sich auch nicht killen), der VDR regagiert auf ein killall nicht mehr, und ein halt schaltet den PC auch nicht komplett aus. Gibts da ne Möglichkeit einen Prozess wirklich richtig hart zu entfernen?


    Wobei es mich auch wirklich interessiert wie es passieren kann das pidof hängt, ps -A funktioniert in dieser Situation problemlos. Erwartet pidof ein reagierendes Programm?



    BTW: Der Watchdog Timer funktioniert generell nicht, dazu gibts hier aber schon nen Thread.


    cu

  • Schau Dir doch, wenn das passiert, mal den Status der Prozesse an (zB mit einem "ps ax").


    Wenn bei dem vdr-Prozess als Status ein "D" steht, kannst Du Abschiessen vergessen, da wird auf I/O gewartet und das lässt sich meines Wissens nach nicht unterbrechen.
    Interessant wäre es, worauf der VDR dann wartet, mit "strace -p <pid>" kannst Du Dich an den Prozess hängen und siehst dann, was er macht (alternativ auch mit "ltrace", je nach dem was halt mehr hergibt).

  • Werde ich mal probieren wenns wieder auftritt, das Problem ist das sich sowas nicht reproduzieren lässt.


    Wenn bei dem vdr-Prozess als Status ein "D" steht, kannst Du Abschiessen vergessen, da wird auf I/O gewartet und das lässt sich meines Wissens nach nicht unterbrechen.


    Ist aber irgendwie ungünstig wenn er unbeaufsichtigt läuft. Die einzige Möglichkeit wäre dann ja ein Watchdogscript welches in diesem Fall per I/O Schnittstelle den Resettaster drückt. Weil selbst ein Neustart geht ja nicht (das Halt schaltet USB und HDD aus aber der Rest bleibt an). Oder man startet ein Programm was nen Kernel OOPS auslöst, weil dann rebootet er ja auch neu (vermutlich auch in diesen Fall).



    Ich habe gerade mal das "exit" (nach der Watchdogmeldung) im VDR durch nen "abort" ersetzt, weil nach dem Halt räumen einige Plugins noch ihre Sachen auf (obwohl ein Grep über den gesamten Source kein atexit gefunden hat). Evtl. hilf das ja schon etwas?


    BTW:
    Exit(1), das macht noch ne ganze Menge dafür das das nen Paniknotausstieg ist.


    abort

    Code
    1. Sep 14 14:26:14 localhost vdr: [3805] PANIC: watchdog timer expired - exiting!
    2. Sep 14 14:26:14 localhost vdr: [3871] [dfb] YUV: action=IDirectFBSurface::Lock(DFBSurfaceLockFlags, void**, int*), result=Resource was destroyed!
    3. Sep 14 14:26:14 localhost vdr: [3871] [dfb] YUV: action=IDirectFBSurface::Lock(DFBSurfaceLockFlags, void**, int*), result=Resource was destroyed!
    4. Sep 14 14:26:14 localhost vdr: [3871] [dfb] YUV: action=IDirectFBSurface::Lock(DFBSurfaceLockFlags, void**, int*), result=Resource was destroyed!
    5. Sep 14 14:26:15 localhost vdr: INIT: VDR beendet -> Exiting with Signal ($[134 - 128]). Restarting...


    cu

  • Interessant wäre es, worauf der VDR dann wartet, mit "strace -p <pid>" kannst Du Dich an den Prozess hängen und siehst dann, was er macht (alternativ auch mit "ltrace", je nach dem was halt mehr hergibt).


    Code
    1. root@dirk-vdr:~# ps -A | grep vdr
    2. 1331 ? 00:00:00 vdrnfofs
    3. 1648 ? 00:00:00 vdr
    4. 1853 tty10 00:00:02 vdr
    5. 1987 pts/0 00:00:00 vdr
    6. root@dirk-vdr:~# strace -p 1853
    7. Process 1853 attached - interrupt to quit


    Und dann hängt strace (ctrl+c geht nicht mehr), genauso wie "ps ax" hängenbleibt.



    BTW: Der Grund für diesen Hänger sind fehlende Schreibrechte im Configverzeichnis (Bastle gerade nen DEB dafür, daher der Fehler).


    us


  • Aber ein killall -9 vdr sollte es immer tun.


    Dachte ich eigentlich auch, aber selbst ein "pidof vdr" bleibt hängen. Höchst seltsam, vermutlich hängt das mit dem softdevice Plugin und Directfb zusammen (das geht ja direkt in den Kernel). Wobei, irgendwie habe ich das Gefühl so was hatte ich noch nicht bevor ich das Fusion Kernelmodul nutzte.


    Edit: Bingo, ohne fusion Modul frisst er sich nicht so fest. Wie ich DirectFB hasse.



    Irgendwie seltsam, wenn ich so google scheine ich der erste zu sein der es schafft nen Programm so festzuhängen das selbst killall -9 es nicht schaft.


    cu