sd_notify(0, "READY=1\nSTATUS=Ready") früher aufrufen?

  • Hallo,


    Mein vdr blieb in vdr.c:817 "cDvbDevice::Initialize();" hängen:

    vermutlich ein Fehler im DVB Treiber :( .

    Systemd hat also nicht mitbekommen, dass vdr schon gestartet war. Und, nach dem timeout, vdr nochmal gestartet. Und nochmal. Und nochmal ...

    Ich hatte sehr viele VDR Prozesse, und ein sehr träges System.


    Klar, ist ein Fehler im Treiber, der sollte gefixd werden.

    Trotzdem: Wäre es möglich, den Aufruf von "sd_notify(0, "READY=1\nSTATUS=Ready");" im VDR weiter noch oben zu schieben, direkt nach dem Laden der Konfigurationsdateien?


    ~Markus

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.4x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • Bei yaVDR ist das so gelöst dass der VDR erst gestartet wird, wenn der Sundtek-Treiber die angeschlossenen Tuner initialisiert hat - dazu muss man die udev-Regel und die sundtek.service anpassen, damit der mediasrv lang genug wartet (achtung, das sind Ansible-Templates, die kann man Systemd nicht 1:1 unterschieben):

    https://github.com/yavdr/yavdr…mediasrv-sundtek.rules.j2

    https://github.com/yavdr/yavdr…ystemd/sundtek.service.j2

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Hallo,


    bei mir gibt systemctl cat sundtek (nach der Installation des sundtek treibers) :


    überzeugt mich irgendwie nicht. Da steht "Wants=graphical.target". Wozu braucht er das?

    Bei yaVDR, wird diese Datei nach der Installation des sundtek Treibers durch eure Datei ersetzt?

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.4x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • Bei yaVDR, wird diese Datei nach der Installation des sundtek Treibers durch eure Datei ersetzt?

    Die Dateien werden vom Playbook nach /etc geschrieben und sollten dann die Dateien des Treibers ersetzen. Das Playbook selbst installiert den sundtek-Treiber aus einem Paket, das darauf getrimmt ist, keine Dinge zu installieren, die stören würden.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Wenn man sd_notify() früher starten würde, dann würde der VDR Prozess trotzdem für immer hängen.

  • Wenn man sd_notify() früher starten würde, dann würde der VDR Prozess trotzdem für immer hängen.

    Stimmt. Aber immerhin würde systemd dann nicht laufend weitere vdr Prozesse starten, die dann auch für immer hängen ...

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.4x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • Kannst du mal deine Systemd-Unit für den VDR zeigen?

    Systemd sollte da keine weiteren Prozesse spawnen - das wartet, bis der gespawnte Prozess meldet, dass er bereit ist (nutzt deine Unit Type=notify?) und wenn das nicht innerhalb des Timeouts passiert, sollte es ihn killen und je nach Restart-Anweisung erneut starten.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Was dieses Problem sogar lösen könnte.

  • systemctl cat vdr:



    TimeoutStartSec=3000 war früher sehr viel kleiner, das habe ich wegen dem hier beschriebenen Problem hochgesetzt.

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.4x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

    The post was edited 1 time, last by mini73: Quote => Code ().