systemd: vdr.service

    Ich werde sicherlich bei Gelegenheit ein RFC zu meinen Ideen vorstellen, aber ohne einen Patch in der Hinterhand hat man keine Diskussionsgrundlage. Aber unsere Vorstellungen gehen in die gleiche Richtung, eine vdr.conf bzw. args.conf und ein args.conf.d/ mit sortierten Dateien, das ist ja auch irgendwie Standard.
    Mit win bisschen Geduld findet sich da sicherlich was.


    Ach ja, was ich auch noch schön finden würde, wäre eine Hilfsfunktion im vdr für Plugins, damit sie sich den passenden Socket-Descriptor von systemd holen können (socket activation). Das sollte auch nicht so schwierig sein.


    Lars

    Zitat von Copperhead

    Immer langsam. Wie gesagt, es sind meine ersten Gehversuche. Die einzige wirkliche Programmiersprache, die ich jemals aktiv genutzt habe ist Java. Naja Perl ist laut Wikipedia auch eine Programmiersprache. Aber die sind beide weit entfernt von C.

    Wenn man schon sd_notify einsetzt um den Watchdog zu triggern, kann man neben WATCHDOG=1 auch mal beim Start READY=1 (und vielleicht irgendwann auch aussagekräftige Strings für STATUS) senden ;)


    Zitat von Mreimer

    Zumindest für mich wäre es das Letzte wenn man jetzt nur für einen sauberen systemd-Start nurnoch einen verpatchten VDR mit bestimmten Plugins nutzen könnte.

    Es kommt einfach darauf an, was man an Funktionalität haben will. Type=forking funktioniert auf jeden Fall und sollte für die meisten Nutzer bei denen der VDR selbst die Ausgabe direkt mitstartet völlig ausreichend sein. Wenn man mit den Mitteln von Systemd die Mainloop des VDR für abhgängige Dienste abwarten oder den Watchdog von Systemd nutzen will, braucht es ein Plugin (oder einen Patch) mit Unterstützung für sd_notify. Mit dbus2vdr kann man mit externen Skripts/Programmen auch auf die "Start", "Ready" und "Stop" Signale über DBus reagieren - was einem noch ein bisschen mehr Informationen über den Status des VDR verschafft:

    Zitat von README

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Zitat von seahawk1986


    Es kommt einfach darauf an, was man an Funktionalität haben will. Type=forking funktioniert auf jeden Fall und sollte für die meisten Nutzer bei denen der VDR selbst die Ausgabe direkt mitstartet völlig ausreichend sein.


    Das der VDR forkt ist mir neu. Standardverhalten ist doch, dass der VDR im Vordergrund bleibt.


    Zitat


    Wenn man mit den Mitteln von Systemd die Mainloop des VDR für abhgängige Dienste abwarten oder den Watchdog von Systemd nutzen will, braucht es ein Plugin (oder einen Patch) mit Unterstützung für sd_notify.


    Das wäre bestenfalls "nice to have". Ich kenne zumindest keinen vom VDR "abhängigen Dienst". Könnte daran liegen, dass der VDR nach außen erstmal nur SVDRP als Schnittstelle anbietet. Und selbst auf die könnte man als abhängiger Daemon warten.


    Prinzipiell stimme ich allem hier genannten voll und ganz zu. Mit der Maßgabe, dass die Änderungen letztlich wirklich im VDR landen. Eigentlich dürfte auch Klaus hier profitieren, denn so langsam zeichnet sich ab, dass irgendwann alle relevanten Distributionen auf systemd setzen.


    Irgendwo hat sich das Konzept der "runvdr" überholt. Die Zeiten, dass DVB-Treiber so instabil sind, dass sie dann und wann einen Reload brauchen, sind vorbei. Ich habe das in über 7 Jahren VDR-Erfahrung nie gebraucht. Komfortabel ist das Konzept des "in der runvdr konfigurierens" auch nie gewesen. Jede Distribution hat sich da eine andere Lösung überlegt um das ganze komfortabel zu bekommen. Mit ein Grund warum ich mich etwas mit der runvdr-extreme befasst habe. Eben weil man dort die Konfiguration in eine echte Konfig-Datei ausgelagert bekommt und optional sogar ein "config.d"-Konzept umgesetzt werden kann.


    Wenn es aber auf einen "unendlichen Patch" hinausläuft, dann wäre meiner Meinung nach das Script, welches die Parameter zusammenbaut und dann via "exec" an den VDR übergibt, die schönere Lösung. Der einzige Patch, der bei mir noch läuft, ist der "MainMenuHooks"-Patch. Der fliegt raus sobald Klaus das Hauptmenü anpassbar gemacht hat und ab diesem Punkt wird mein VDR niemehr einen Patch sehen der keine Aussicht auf Übernahme in den VDR hat.


    In meinem damaligen Versuch ist es darauf hinausgelaufen, dass Klaus die Config-Datei(en) gerne analog zu den Parametern an der Befehlszeile parsen möchte. Also mit getopt_long interpretieren. Um lange Zeilen einfach umbrechen zu können haben wir uns darauf geeinigt, dass ein führendes Leerzeichen in einer Zeile diese zur vorherigen hinzugefügt wird. Im ganz groben hatte ich auch schon etwas zusammengefrickelt. Allerdings wohl mit 90% zu viel Code weil ich echt wortwörtlich gegen die Tücken von C, inklusive dieses ganzen Speicher/Pointer-Wahnsinns, gekämpft habe.


    Für ein separates "/etc/vdr" war Klaus aufgeschlossen. Schon aus Sicherheitsgründen macht das Sinn, denn der Bereich, in dem die Plugin-Konfig liegt (/var/lib/vdr), kann ja vom VDR-User geschrieben werden während die VDR-Config schon gelesen wird bevor der VDR die Root-Rechte abgegeben hat.


    Viel mehr Infos habe ich nicht, denn spätestens als ich durch einen unvorsichtigen Aufräumvorgang (warum habe ich denn da den VDR-Source hinentpackt???) meine Arbeit verloren habe, hatte ich die Schn**** voll.


    Wenn es der Sache dienlich ist, könnte ich meinen damaligen Stand wohl in ein paar Stunden Arbeit nochmal reproduzieren.


    Und ein Usermode-Tool braucht es ja auch noch (vdrctl). Wenn sich niemand anderes findet, dann würde ich versuchen hier etwas zu scripten das analog zu systemctl funktioniert.

    Ich arbeite mit Vorliebe auch nur an Patches, die es irgendwann in den vdr schaffen sollten. Bei dynamite war mir klar, dass er es so nicht schaffen würde, aber das waren auch einfach nur erste Gehversuche mit udev usw..


    Dass die getopt-Schleife benutzt werden sollte, ist eigentlich auch klar, es darf keinen Komfortverlust beim Programmieren geben.


    Ich weiß nicht genau, warum man da eine besondere Syntax für Zeilenumbrüche braucht, ich würde einfach alle Nicht-Kommentar-Zeilen in eine lange Parameterzeile zusammenfassen und dann für getopt in die einzelnen Strings zerlegen. Zeilenumbrüche werden dann einfach mit Leerzeichen ersetzt. So klappt es bei den plugin.*.conf-Dateien bei Debian/Ubuntu schon lange sehr gut (auch, wenn es noch ein Shellscript vor dem Start macht).


    vdrctl:
    Unabhängig von der Implementation könnte man schon mal Doku für die Aufrufsyntax schreiben. Dann könnte man es zur Not in älteren Distributionen neu implementieren und dann eben auch für die alte Debian-Struktur wiederverwenden.


    Beispiele, nur als Brainstorming zu verstehen:


    Bei den "del"-Aufrufen reicht nur die Option ohne Parameter.
    Die "args"-Aufrufe können mehrere Parameter in einem Rutsch setzen.
    "get" zeigt einfach an, was gesetzt ist.


    Für ein Backup von Source kann ich nur github empfehlen. Auch ein Grund, warum ich so selten aufräume, sondern irgendwann einfach eine neue Platte kaufe und die alte liegen lasse. Sowas passiert jedem mal. :)


    Lars.

    Zitat von mini73


    Ich weiß nicht genau, warum man da eine besondere Syntax für Zeilenumbrüche braucht, ich würde einfach alle Nicht-Kommentar-Zeilen in eine lange Parameterzeile zusammenfassen und dann für getopt in die einzelnen Strings zerlegen.


    Zeilenumbrüche deshalb weil man dann Plugin-Parameter auf mehrere Zeilen aufteilen kann. Je einen Kommentar drüber und die Konfig-Datei wird selbsterklärend. Eine nur maschinenlesbare Konfiguration wäre für mich ein No-Go.


    Was vdrctl angeht: Das einzige, das ich im ersten Ausbaustand brauchen würde, wäre "vdrctl [enable|disable] $PLUGINNAME". Die Argumente selber möchte ich schon selber in einer Config-Datei pflegen können, in der ich mir dann auch hilfreiche Kommentare wünsche. Irgendwie passt automatisches Editieren meiner Meinung nach nicht so recht zum VDR. Und systemctl kennt auch keine magischen Parameter um damit dropins oder gar unit-Files automagisch zu editieren.


    Das ganze dann analog zu systemd mit zwei Pfaden ausführen. Einmal unter /usr/lib für die mitinstallierten Default-Configs und einmal unter /etc/ für die vom Benutzer angepassten. Benutzer-Configs übersteuern gleichnamige System-Configs. Nicht konfigurierbare Plugins könnte man dann direkt mit einer kleinen Default-Config-Datei ausliefern, die dann nur den Start des Plugins übernimmt. Konfigurierbare dagegen würde ich direkt unter /etc ablegen damit der Benutzer hier seine Konfiguration vornehmen kann.


    Wenn eine Distribution gerne automatisch Konfig-Dateien generiert, dann darf sie das natürlich gerne tun, aber ich möchte gerne nach wie vor in einer (möglichst selbsterklärenden) Config-Datei konfigurieren.


    Default-Configs, inklusive Kommentare, könnten Plugin-Autoren dann auch direkt mitliefern.

    Die /usr/lib-/etc-Aufteilung finde ich auch gut.
    Bei Debian sehen die plugin.*.conf-Dateien z.B. so aus (z.B. dbus2vdr bei yaVDR):


    Leerzeilen und alle, die mit "(Whitespace)#" beginnen, werden ignoriert, der Rest wird zu einer langen Zeile zusammengesetzt und an den vdr verfüttert.


    "disable/enable plugin" halte ich auch für den wichtigsten Befehl, "list plugins" ist auch ganz praktisch, um zu sehen, was installiert ist. Und zumindest "get-args" könnte ich mir auch vorstellen, damit man sieht, was man da eigentlich eingetragen hat in der Datei. Dann muss man nicht suchen und falls man mehrere Dateien angelegt hat, die nicht in der richtigen Reihenfolge zusammensetzen.


    Lars.

    Zitat von mini73


    Bei Debian sehen die plugin.*.conf-Dateien z.B. so aus (z.B. dbus2vdr bei yaVDR):
    ...


    So wie ich die Anforderungen von Klaus verstanden habe, sollen Plugin-Configs in Etwa so aussehen:


    Code
    --plugin=dbus2vdr
 --shutdown-hooks=/usr/share/vdr/shutdown-hooks
 --shutdown-hooks-wrapper=/usr/share/vdr-plugin-dbus2vdr/shutdown-wrapper
 --upstart
# --network


    Also eigentlich keine eigene Untergruppe "Plugin-Config" sondern nur "Config-Dateien in neutraler Syntax die hintereinander gelesen werden".


    Zitat


    "disable/enable plugin" halte ich auch für den wichtigsten Befehl, "list plugins" ist auch ganz praktisch, um zu sehen, was installiert ist. Und zumindest "get-args" könnte ich mir auch vorstellen, damit man sieht, was man da eigentlich eingetragen hat in der Datei. Dann muss man nicht suchen und falls man mehrere Dateien angelegt hat, die nicht in der richtigen Reihenfolge zusammensetzen.


    Volle Zustimmung. Kommt so auch dem, was systemctl kann, sehr nahe.

    Zitat von Mreimer

    Das der VDR forkt ist mir neu. Standardverhalten ist doch, dass der VDR im Vordergrund bleibt.

    Ich meinte das wenn man wie von Copperhead vorgeschlagen die Argumente über ein startvdr-Skript zusammenbaut - wenn man es direkt startet (das hatte ich gestern falsch gepostet) braucht es natürlich Type=simple.

    Zitat von Mreimer

    Ich kenne zumindest keinen vom VDR "abhängigen Dienst". Könnte daran liegen, dass der VDR nach außen erstmal nur SVDRP als Schnittstelle anbietet. Und selbst auf die könnte man als abhängiger Daemon warten.

    Das muss dann aber jedes abhängige Programm selbst implementieren. Wenn man schon die Möglichkeit hat, sollte man die Fähigkeiten von systemd möglichst optimal ausnutzen.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Zitat von Mreimer

    Also eigentlich keine eigene Untergruppe "Plugin-Config" sondern nur "Config-Dateien in neutraler Syntax die hintereinander gelesen werden".


    Ok, verstehe, alpha-numerisch sortierte Dateien, damit man die Reihenfolge festlegen kann (00_..., 01_... usw.).
    Bei Plugins müssen die Parameter für ein Plugin ja in Anführungszeichen eingeschlossen werden. Ich nutze da nur

    Code
    vdr ... "-Pplugin --plugin-parameter"


    , sieht das bei langem Parameter genauso aus, also

    Code
    vdr ... "--plugin=plugin --plugin-parameter"


    ?
    Die Plugins sind also schon etwas besonderes, oder? Es soll also für die Plugins eine Erleichterung in den Dateien geben, so dass man nicht die Anführungszeichen setzen muss. Dafür dann das Leerzeichen am Anfang?
    Ich dachte eher an eine Config-Datei pro Plugin (oder auch ein Config-Dir pro Plugin, obwohl das vermutlich zu viel ist), dass dann an besondere Stelle verlinkt ist, wenn das Plugin geladen werden soll. Und der Pluginname sollte im Dateinamen stehen, damit klar ist, für welches das ist, und man den Pluginnamen nicht noch mal explizit angeben muss. Bei dir muss es ja dann eigentlich für jedes Plugin mindestens eine Minimaldatei mit "--plugin=name" geben, wenn das Plugin geladen werden soll, bei mir würde eine leere Datei reichen.


    Muss ich mal drüber nachdenken.
    Kannst du mal deine Verzeichnisstruktur beispielhaft auflisten?


    Lars.

    Zitat von Mreimer

    auch andere Init-Systeme unterstützen will


    Das verstehe ich nicht. Welches andere Init-System?
    Alle großen Distributionen haben jetzt schon, oder werden in Zukunft systemd einsetzen.


    Im Anhang mal das systemd-Plugin. Watchdog funktioniert einwandfrei. Die richtige Position für READY=1 habe ich von dbus2vdr abgeschaut. Ich hätte es wahrscheinlich bei Start eingebaut.
    Jetzt wo ich die eigentliche Funktionalität sehe, wäre wohl sdnotify Plugin der bessere Name.

    Zitat von mini73


    Ok, verstehe, alpha-numerisch sortierte Dateien, damit man die Reihenfolge festlegen kann (00_..., 01_... usw.).


    Ja, genau so.


    Zitat


    Die Plugins sind also schon etwas besonderes, oder? Es soll also für die Plugins eine Erleichterung in den Dateien geben, so dass man nicht die Anführungszeichen setzen muss. Dafür dann das Leerzeichen am Anfang?


    Ja. Zumal du an getopt_long ohnehin ohne Anführungszeichen gehst. Die sind nur für die Shell. Bei Unix-Systemen werden die Parameter direkt als Array übergeben.


    Zitat


    Ich dachte eher an eine Config-Datei pro Plugin (oder auch ein Config-Dir pro Plugin, obwohl das vermutlich zu viel ist), dass dann an besondere Stelle verlinkt ist, wenn das Plugin geladen werden soll. Und der Pluginname sollte im Dateinamen stehen, damit klar ist, für welches das ist, und man den Pluginnamen nicht noch mal explizit angeben muss. Bei dir muss es ja dann eigentlich für jedes Plugin mindestens eine Minimaldatei mit "--plugin=name" geben, wenn das Plugin geladen werden soll, bei mir würde eine leere Datei reichen.


    Das ist halt mein Stand aus meinem Mailverkehr mit Klaus. Weitere Infos habe ich auch nicht. Ich fand den Stand, den ich dir dargelegt habe, dann eigentlich recht brauchbar. Zumal ich für diese Struktur schon mehr oder weniger die unverbindliche Zusage hatte, dass das so auch Bestandteil des VDR werden könnte.


    Zitat


    Kannst du mal deine Verzeichnisstruktur beispielhaft auflisten?


    Schicke ich später nach. Habe gerade kein System mit systemd zur Hand und die grobe Pfadstruktur würde ich an systemd anlehnen wollen.

    Zitat von Copperhead


    Das verstehe ich nicht. Welches andere Init-System?
    Alle großen Distributionen haben jetzt schon, oder werden in Zukunft systemd einsetzen.


    Ich schreibe auch Programme wo ich mich zumindest theoretisch nicht auf Linux fixieren möchte. Zum Beispiel programmiere ich zeitweise auch für Solaris.


    Zitat


    Im Anhang mal das systemd-Plugin. Watchdog funktioniert einwandfrei. Die richtige Position für READY=1 habe ich von dbus2vdr abgeschaut. Ich hätte es wahrscheinlich bei Start eingebaut.
    Jetzt wo ich die eigentliche Funktionalität sehe, wäre wohl sdnotify Plugin der bessere Name.


    Wenn es ein distributionsweit halbwegs gleiches ".service"-File geben soll und dieses einen "Vanilla VDR" starten können soll, dann müsste das ganze wohl mit bedingter Kompilierung direkt in den VDR...

    KISS. Wenn dich der VDR-Watchdog nicht stört, dann lasse ihn drin. So steht es jedem frei, auch ohne Neukompilieren, doch den VDR-Watchdog zu nutzen.


    Und ich kann mir schon vorstellen, sofern dein Patch nicht extrem groß wird, dass Klaus da auch Interesse hat. Irgendwann kommt der Tag, an dem er auch einen VDR mit systemd aufstarten möchte...

    Dann also so, wie im Anhang.


    Noch simpler geht es wohl nicht.
    READY=1 wird gesendet, wenn der vdr-interne Watchdog das erste mal gestartet wird.
    WATCHDOG=1 wird gesendet, wenn der vdr-interne Watchdog zurückgesetzt wird.


    Man könnte zusätzlich noch mit sd_watchdog_enabled prüfen, ob systemd überhaupt ein Watchdog-Signal erwartet.

    Zitat von Mreimer

    Ja. Zumal du an getopt_long ohnehin ohne Anführungszeichen gehst. Die sind nur für die Shell. Bei Unix-Systemen werden die Parameter direkt als Array übergeben.


    Ok, alles soweit verstanden.


    Mein Bauch wehrt sich noch ein wenig gegen die Leerzeichen am Anfang, weil die evtl. schnell mal irgendwo gesetzt sind, wo sie eigentlich nicht hingehören oder fehlen, wenn man sie braucht. Ist halt etwas implizit und keine explizite Deklaration. Jetzt im Moment fällt mir aber auch nichts gescheites anderes ein, außer eben pro Plugin eine eigene Datei, so dass es klar ist, dass diese ganzen Parameter an das Plugin weitergereicht werden.


    Oder man wechselt zu ini-Style:


    Die einzelnen Abschnitte lassen sich dann auf einzelne Dateien verteilen.


    Lars.

    Wie schon erwähnt: Das mit dem Leerzeichen am Anfang war ein Vorschlag von Klaus. Bevor du es grundlegend anders implementierst, frage vielleicht vorher mal kurz nach...


    Mein Vorschlag war ursprünglich das ganze auf cNestedItems aufzusetzen. VDR-Einstellungen auf die oberste Ebene und pro Plugin eine "Unterebene". Mit den Leerzeichen könnte ich aber auch leben. Wie schon erwähnt war ich froh, dass sowas überhaupt eine Chance hat, direkt in den VDR zu wandern.

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden