[Patch] VDR 1.6.0 wird nicht korrekt entladen

  • Zitat

    Original von TomJoad
    Ihr habt doch beide Recht. Wenn vdr mit

    Code
    export LD_ASSUME_KERNEL=2.4.1

    startet wie z.B. bei easyvdr, bekommt jeder thread eine eigene PID.


    LD_ASSUME_KERNEL=.. macht eigentlich keinen Sinn, da der VDR seit Version 1.4.x NPTL kompatibel ist. Vermutlich gibts aber irgendein Plugin, das unbedingt unterstützt werden muß und das eine Library verwendet, zu der man keine Sourcen hat und die ohne NPTL Support kompiliert wurde. Da sollte man mal fragen, wie es denn mit der Lizenz von EasyVdr und den verwendeten Programmen aussieht, GPL bzw. LGPL konform ist das sicherlich nicht.


    Gruß
    e9hack

  • Zitat

    Original von ardi
    ich habe jetzt herausgefunden, dass Easyvdr 10x (im Sekundentakt) versucht den vdr zu beenden.


    In runvdr gibts bei EasyVdr folgend Sequenz:

    Da hatten die EasyVdr-Entwickler nicht unbedingt eine Sternstunde. Man sendet nicht einfach SIGTERM im Sekundentakt an eine Anwendung. Normalerweise sendet man einmal SIGTERM. Wenn sich das Programm nicht innerhalb wenigen Sekunden beendet, wird ein SIGKILL hinterher geschickt. Für sowas verwendet man killproc. Da kann man auch die Wartezeit angeben. Die Schleife entfällt dann.


    Gruß
    e9hack

  • Ich habe jetzt feststellen müssen, dass sich der VDR trotz meines Patches manchmal immer noch nicht korrekt beendet.


    Erst nachdem ich "export LD_ASSUME_KERNEL=2.4.1" rausgenommen habe funkt es.


    Vermutlich kommen zu schnell zu viele SIGTERMs. Da der Standard-Signalhändler gesetzt wird bevor der VDR-Signalhändler aufgerufen wird, trifft sicherlich ein weiterer SIGTERM ein, bevor sich der VDR-Signalhändler selbst wieder gesetzt hat.


    Ohne "export LD_ASSUME_KERNEL=2.4.1" kommt jetzt nur noch ein SIGTERM. Bei Easyvdr jedoch im Sekundentakt, wodurch mein Patch trotzdem nötig ist.



    Ob die vorgehnsweise von Easyvdr, dem VDR im Sekundentakt ein SIGTERM zu verpassen, sinnvoll ist oder nicht vermag ich nicht zu beurteilen.


    Ich bin aber der Meinung, das die VDR Entwickler mit

    Code
    // Reset all signal handlers to default before Interface gets deleted:
      signal(SIGHUP,  SIG_DFL);
      signal(SIGINT,  SIG_DFL);
      signal(SIGTERM, SIG_DFL);
      signal(SIGPIPE, SIG_DFL);
      signal(SIGALRM, SIG_DFL);


    etwas übers Ziel hinausgeschossen sind. Schließlich soll ja nur verhindert werden, dass das "Interface" (durch den Signalhandler) angefasst wird, wenn es nicht mehr existiert. Dies ist durch meinen Patch, glaube ich, besser gelöst.


    ardi

    :welle ASRock K10N78FullHD-hSLI R3.0, Atlon64 X2 4850e (45W), 2GB RAM,500GB SATA, SkyStar2+TT-S21600, yaVDR

  • Zitat

    Original von ardi
    Ob die vorgehnsweise von Easyvdr, dem VDR im Sekundentakt ein SIGTERM zu verpassen, sinnvoll ist oder nicht vermag ich nicht zu beurteilen.


    Ich halte das für falsch. Wenn Du den Timeoutwert auf 5sec hochsetzt, benötigst Du den Patch nicht mehr.


    Zitat

    Ich bin aber der Meinung, das die VDR Entwickler mit

    Code
    // Reset all signal handlers to default before Interface gets deleted:
      signal(SIGHUP,  SIG_DFL);
      signal(SIGINT,  SIG_DFL);
      signal(SIGTERM, SIG_DFL);
      signal(SIGPIPE, SIG_DFL);
      signal(SIGALRM, SIG_DFL);


    etwas übers Ziel hinausgeschossen sind. Schließlich soll ja nur verhindert werden, dass das "Interface" (durch den Signalhandler) angefasst wird, wenn es nicht mehr existiert. Dies ist durch meinen Patch, glaube ich, besser gelöst.


    Normalerweise wird ja auch nur 1x SIGTERM gesendet. Daher ist es völlig korrekt, die Signalhandler am Ende auf Default zurückzusetzen.


    Gruß
    e9hack

  • Zitat

    Normalerweise wird ja auch nur 1x SIGTERM gesendet. Daher ist es völlig korrekt, die Signalhandler am Ende auf Default zurückzusetzen


    Im Grunde stimme ich dir zu. Aber:


    Wenn es "normal" ist, dass nur 1x SIGTERM gesendet wird, dann kann ich mir auch sparen die Signalhandler am Ende auf Default zu setzen.
    Das wird beim vdr nur getan (zumindest habe ich das so verstanden), um eine Aktion des Handlers zu unterbinden, für die es keine Grundlage mehr gibt (deleted Interface).


    Wenn es Unnormalerweise doch passiert, das SIGTERM öffters kommt, kann ich doch, wenn ich die Möglichkeit dazu habe, eine unerwünschte Aktion verhindern (und somit den Prozess sauber beenden) und muß nicht gleich den Prozess killen.


    Das meine mit "etwas übers Ziel hinausgeschossen"


    ardi

    :welle ASRock K10N78FullHD-hSLI R3.0, Atlon64 X2 4850e (45W), 2GB RAM,500GB SATA, SkyStar2+TT-S21600, yaVDR

Jetzt mitmachen!

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