VDR Start mit systemd Unit - bitte um Feedback

  • Hallo,


    ich kenne den Thread hier im Forum, wo es schon einmal um eine Start Unit für den VDR ging. Hier gab es unterschiedliche Lösungen sowie Patches für den VDR damit er auf notifys reagiert.


    Mir reicht es jedoch aus, wenn ich meine bestehende Konfiguration mit runvdr-extreme von init.d nach systemd gut übertragen bekomme.


    Mich würde interessieren, was ihr zu der folgenden Unit meint. So gut kenne ich mich damit noch nicht aus, so dass ggf. der ein oder andere Verbesserungen sieht.

    Laufen tut es erst einmal. Ich finde das Stoppen des VDR dauert aber recht lange - kann aber auch sein, dass es mit runvdr-extreme auch vorher so war.


    Hier mal meine Service-Datei:


    Dazu die vor/danach Skripte:


    /etc/4vdr/tools/runvdr-pre.sh


    /etc/4vdr/tools/runvdr-post.sh


    Gruss

    Marcus

    My VDRs:

  • Du hast Recht. Es wurde viel diskutiert. Allerdings sind die nötigen Features alle bereits in den VDR gewandert. Hier nochmal vielen Dank an mini73 der den Code für die Config-Dateien geschrieben hat.


    Was ich schonmal ohne viel "Durchlesen" sagen kann, ist, dass deine Lösung zu "fett" ist.


    So machen wir's bei Arch Linux:

    https://github.com/VDR4Arch/vd…ob/master/vdr/vdr.service

    That's it. Mehr braucht es auch nicht.


    Wenn du den VDR mit Ausgabe betreibst, dann wird das hier noch nachinstalliert (als Drop-In)

    https://github.com/VDR4Arch/vd…er/vdr-xorg/vdr-xorg.conf

    Das Drop-In ergänzt das Environment und zieht einen X-Sever an. Damit das Drop-In geht muss "xlogin" installiert sein.


    So wie das aussieht nutzt du immer noch eine "runvdr". Die wird eigentlich garnicht mehr gebraucht.


    Und die anderen Dienste haben in aller Regel selber Systemd-Units. Um die müsstest du dich garnicht kümmern. Für Alsa gibt es sowas zum Beispiel definitiv und was cpufreq angeht:

    https://wiki.archlinux.org/ind…y_scaling#Userspace_tools


    Was ich ganz vergessen habe: Das der Kram bei dir unter /etc liegt ist sicher historisch bedingt. Wenn schon alles an einem Ort, dann packe es wenigstens nach /opt...

  • So wie das aussieht nutzt du immer noch eine "runvdr". Die wird eigentlich garnicht mehr gebraucht.


    Ups, interessant. Die nutze ich auch noch. Mir scheint da muss ich mich mal up-to-date bringen. Wie wird denn da jetzt festgelegt welche Plugins mit welchen Parametern gestartet werden?

    VDR2: ASRock J4105-ITX, DVBSky S952, openSUSE Tumbleweed, VDR 2.4.7

    softhddevice/vaapidevice, DFAtmo, xmltv2vdr, tvscraper, tvguideng, VDRAdmin-AM (alles git, aber alt)

  • aus der manpage:

    Üblicherweise legt man nun unter /etc/vdr/conf.d/ eine Datei für jedes Plugin an, die mit .conf endet. Die enthält mindest den Namen des [Plugins] in eckigen Klammern und optional alle Optionen. Zum Deaktivieren benennst Du die Datei einfach in irgendwas ohne .conf um. Oder Du verlinkst die Dateien nur von extern in den Ordner und löschst den Link, wenn Du das Plugin nicht mehr brauchst.

    Startest Du nun einfach vdr ohne weitere Parameter, dann wird das Verzeichnis abgeklappert und die Plugins gestartet.


    'vdr --showargs' zeigt Dir alle gesetzten Parameter an.


    Christian

  • Hallo,


    das mit der Konfiguration der zu startenden Plugins - direkt mit dem VDR - habe ich irgendwie überlesen. Wo ändere ich hierfür das Default-Verzeichnis (/etc/vdr/conf.d)? Ich mag die Defaults nicht, die sind mir alle überall verstreut (/var/lib/vdr, /etc/vdr, /usr/lib...) - daher mein - richtig erkannt - historisches /etc/4vdr. Eine gute Idee, das gleich auf /opt umzuziehen. Ich habe gern alles an einer Stelle konfiguriert um es auch schnell mal umziehen zu können.


    So, ich scanne mal meine runvdr.conf / Gründe für runvdr-extreme:

    1. Plugins:

    ersetzbar mit /etc/vdr/conf.d und hoffentlich änderbar auf /opt/vdr/plugins oder so...


    2. DVB-Treiber laden/entladen

    sollte heutzutage nicht mehr notwendig sein, könnte ich in einem Pre/Post-Script unterbringen, wenn erforderlich


    3. Nicht-Plugin-Konfigurationen, z.B. Video-DIR, config-DIR, LIRC, RECORDCMD, SVDRPPORT, LANGUAGE etc.

    wäre hier noch offen


    4. XSERVER starten (mein VDR bootet nicht automatisch in die X-Umgebung)

    wäre noch offen, könnte ggf. softhddevice übernehmen, aber dann wäre man Pluginabhängig (z.B. mit xineliboutput/xine würde es nicht gehen)


    5. Timeout für TERM/KILL des VDR

    sollte über die Unit möglich sein, ist in dem o.g. Beispiel aber nicht konfiguriert.


    Sonstiges:

    Ich wüsste nicht, dass man CPUFreq sagen kann, dass er nur beim Laufen des VDR die CPU auf 2GHz halten soll (ist notwendig wegen einem Problem VDPAU/GPU des AMD Systems). Kann ja im Pre/Post-Script bleiben, ebenso wie der Rest bis auf ALSACTL, dass weggelassen werden kann.


    Bleibt erstmal noch Punkt 3 und 4 um mein "geliebtes" runvdr-extreme zu ersetzen.

    My VDRs:

  • Punkt 3 geht genauso über die Config-Dateien. Kannst da ja mal schauen wie wir es unter Arch machen.


    Und was du "verstreut" nennst, nennt sich "FHS". Unter Unix hat alles und jede "Art" von Datei ihren fest vorgegebenen Platz. Diese "Ordnung" erwarte ich bei meinen Systemen auch, da ich dann durch "intuitive Suche" dann extrem oft direkt ohne Doku-Lesen ans Ziel komme. Bei Arch kommen wir dem "Optimum" da hoffentlich schon recht nahe. Andere Distributionen haben da noch an einigen Details gedreht.


    Wegen X-Server-Start. Das ist und bleibt ein Hack. Bei Arch ist das mit xlogin und dem verlinkten Dropin gelöst. Richtig sauber geht nur wenn man Backend und Frontend getrennt startet und das Frontend dann sauber in eine Session packt. Da der VDR neben TV keine Multimedia-Fähigkeit hat, ist der Mehrwert durch eine "saubere Session" aber begrenzt.


    Deshalb auch als Dropin. Ohne dieses ist der VDR sauber als Dienst gestartet ohne "von hinten durch die Brust" nen X-Server hochzuleiern. Kodi starte ich dann in einer sauberen Session via xinit separat.

  • Punkt 3: wie schon erwähnt einfach eine conf-Datei mit dem Abschnitt [vdr] machen und dort die vdr-Optionen eintragen.


    Das Verzeichnis für die conf-Dateien kannst du beim Übersetzen des vdr verändern (ARGSDIR, siehe Make.config.template), für sinnvoll halte ich es nicht. Du kannst aber natürlich an anderer Stelle ein Verzeichnis anlegen und es nach /etc/vdr/conf.d verlinken.


    Und wenn man sich mit den anderen Verzeichnissen wie /run, /var/cache usw. auseinandergesetzt hat, versteht man auch, wozu die da sind. Das lohnt sich.


    Lars

  • Danke für die Tipps/Neuerungen - bin auf einem guten Weg. Das mit conf.d funktioniert sehr gut - ich habe das VDR CONF-DIR nun nach /opt umgezogen und conf.d verlinke ich dort hin.


    Die VDR-Konfiguration ändere somit wie folgt:

    Code
    --config=/opt/vdr
    --video=/video
    --record=/opt/vdr/tools/rwrapper.sh
    --shutdown=/opt/vdr/tools/safepower.sh
    --grab=/tmp
    --port=6419
    --watchdog=90
    --epgfile=/video/epg.data
    --log=3
    --lirc=/var/run/lirc/lircd


    Ich nutze nun folgende Units:

    vdr.service

    Das ganze kann ich mit ExecPre/Post ja noch ausbauen.


    Und X wird nun mit dieser Unit gestartet:

    xorg-vdr.service

    Code
    [Unit]
    Description=X Server für VDR
    BindsTo=vdr.service
    
    [Service]
    ExecStart=/usr/bin/X -br -nolisten tcp :0
    
    [Install]
    WantedBy=multi-user.target


    vdr.service kann ich nun starten und stoppen, und X startet/stoppt gleichzeitig mit.


    Was jedoch noch nicht funktioniert, ist der Restart des VDR, wenn er mal abschmiert. Gebe ich killall vdr ein, wird der service nicht neu gestartet. Restart=on-failure scheint irgendwie nichts zu bewirken?!

    My VDRs:

  • Hallo,


    ich glaube die Version hatte ich von hier.


    Ich habe den Wert komplett auskommentiert/entfernt.


    Der Vollständigkeit halber, hier meine bisher gut laufenden Units:


    vdr.service (LimitCORE nur für Testzwecke)


    devices (udev)

    Code
    cat /etc/udev/rules.d/80-tbs-i915.rules
    # symlinks and tags for frontend0 of the DVB-S card and for graphic card (drm)
    SUBSYSTEMS=="pci", DRIVERS=="cx23885", ATTRS{subsystem_device}=="0x8888", ATTRS{subsystem_vendor}=="0x6981", SYMLINK+="tbscard", TAG+="systemd"
    SUBSYSTEMS=="pci", DRIVERS=="i915", ATTRS{subsystem_device}=="0x2212", ATTRS{subsystem_vendor}=="0x1849", SYMLINK+="i915card", TAG+="systemd"

    xorg.service

    => ohne das require für das DRM-Interface startete der X-Server - nach Nutzung von media_build - immer zu früh und fand kein Device. Mit den Original-Kernelmodulen hatte ich den Effekt nicht. Leider brauche ich die Module für meine TBS Karte aufgrund von "mpeg risc op code error" noch - mit Kernel 4.20 sollte es gelöst sein.


    vdradmind.service


    In vdr-exec-stxxx.sh kann ich die Module nun starten/stoppen - ist aber nicht zwingend notwendig.


    killall vdr klappt aber immer noch nicht - scheint wohl am exit code 0 zu liegen:

    My VDRs:

  • systemd - bisher konnte ich mich davor erfolgreich drücken. Nach dem vdr Update von Debian 8 auf 10 steh ich nun ratlos da.


    Das Liveplugin sowie sämtliche in der /etc/vdr/default befindlichen Startparameter werden nicht geladen. Wie kann ich Debian 10n dazu bringen den VDR direkt zu starteb ( kein crontab oder /etc/rc.local, sondern mit sytemd )


    Wo muss ich nachgucken um dem Grund für den Fehler im Live Plugin zu finden ?

  • systemd - bisher konnte ich mich davor erfolgreich drücken. Nach dem vdr Update von Debian 8 auf 10 steh ich nun ratlos da.

    Dann lies doch endlich mal die Dokumentation...

    Wie kann ich Debian 10n dazu bringen den VDR direkt zu starteb ( kein crontab oder /etc/rc.local, sondern mit sytemd )

    Das vdr-Paket bringt eine passende Systemd-Unit mit (https://salsa.debian.org/vdr-t…master/debian/vdr.service. Die beiliegende Dokumentation für das VDR-Paket (in /usr/share/doc/vdr/) erzählt dir alles wissenswerte über die Änderungen am Paket in den letzen Jahren, wie man Start-Argumente für Plugins konfiguriert usw.

    Wo muss ich nachgucken um dem Grund für den Fehler im Live Plugin zu finden ?

    Wie wäre es mit den Logdateien? Systemd und journald setzen das sehr bequem um - wenn du z.B. die Logausgaben für die vdr.service seit dem Booten sehen willst: journalctl -u vdr -b

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • "Dann lies doch endlich mal die Dokumentation..."


    bin dabei ;)

    => s. Verständnisfrage zu /etc/vdr/conf.d


    Hätte ich das mal eher gefunden : https://www.yavdr.org/documentation/0.6/de/ch01s06.html

  • Verzeichnis ist aber /var/lib/video und der vdr läuft wenn er mit systemd gestartet ist als root ( zumindest werden die Aufnahmen mit root.root erstellt ).

    Er startet als root und sollte dann die Berechtigungen auf den User VDR dropppen, weil in der /etc/vdr/conf.d/00-vdr.conf standardmäßig das Start-Argument --user=vdr gesetzt ist: https://salsa.debian.org/vdr-t…er/debian/00-vdr.conf#L14

    Abgesehen davon findet sich keine Information über die Syntax der /etc/vdr/conf.avail/vdr.conf Datei.

    Wichtig sind die Dateien in /etc/vdr/conf.d/ - vgl. https://salsa.debian.org/vdr-t…/debian/README.Debian#L58.

    Die Syntax der Dateien wird in der Manpage des VDR beschrieben (man 5 vdr) : https://manpages.debian.org/bu….html#COMMANDLINE_OPTIONS

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Dank https://www.yavdr.org/documentation/0.6/de/ch01s06.html sind alle Unklarheiten beseitigt ;)

  • Die von mir geschriebene yaVDR-Dokumentation hatte ich nicht verlinkt, weil vdrctl soweit ich weiß noch nicht für Debian paketiert worden ist (aber du kannst dir das Paket gerne aus dem yaVDR-PPA holen, wenn es dir hilft).

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Vvdrctl ist bequem aber das geht zur noch manuell. Wichtig ist das Zusammenspiel der conf Dateien deren Verlinkung und Inhalt. Funktioniert wie beim Apache, find' ich klasse.


    In dem Sinne : Danke ;)


    PS : für versierte User wäre ein Hinweis "Configaufbau wie beim Apache" sehr hilfreich.

  • Nur, wenn man Apache kennt... :)


    Aber mitterweile machen das ja schon mehrere Programme mit solchen Dateien, weil es sich ja auch bewährt hat.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!