systemd: vdr.service

  • Quote

    Sorry, aber das kann man keinem VDR-Nutzer wirklich antun wollen.


    Der Nutzer hat damit nix zu tun, der Systemadmin muss einmalig bei der Installation neuer DVB Hardware ne UDEV Regel erstellen.


    Gesendet von meinem ALCATEL ONE TOUCH 997D mit Tapatalk 2

  • Läuft wohl letztlich für eine einfache Lösung wirklich darauf hinaus sich irgendwo zu merken wie viele Devices erwartet werden.

    Die Lösung ist weder einfach noch vom User, der die Interna nicht kennt, wirklich erwartbar. Es sollte IMHO nicht sein, dass ein VDR, dem man im Ausgeschalteten Zustand einen Tuner wegnimmt danach nicht mehr normal startet. Ich finde eine statische Lösung wie bei Gen2VDR vertretbar (bei mir sieht es aktuell nicht anders aus), bei der man die Anzahl der Tuner von Hand angeben kann, für den unbedarften User halte ich die Lösung über das dynamische Einbinden von DVB-Geräten aber deutlich einfacher - Plug and Play.


    Die udev-Regeln braucht man ja nur für Spezialfälle, wenn die Reihenfolge der Tuner wirklich eine Rolle spielt (LNB-Sharing, böse Plugins im Mix mit CI-Modulen an DVB-Karten, "dumme" USB-DVB-Karten, die einen intialen Tuning-Versuch brauchen usw.)

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • böse Plugins im Mix mit CI-Modulen an DVB-Karten


    Wer kommt denn auf so blöde Ideen? Wenn schon, dann alles über Software.

    Und "Systemadmin" dürfte in den allermeisten Fällen gleich "Benutzer" sein.


    Exakt.


    Das Einzige, was ich für vertretbar halte, ist das von Mreimer schon angesprochene Skript, dass automatisch beim Ausschalten läuft. Eine feste Reihenfolge erzeugt man damit aber auch nicht, sollte aber theoretisch machbar sein.
    Ich befürchte aber, dass dadurch die Bootzeit verlängert wird.

  • Und "Systemadmin" dürfte in den allermeisten Fällen gleich "Benutzer" sein.


    Und solange man Konzepte mit dieser Weisheit im Hinterkopf entwickelt wird man keine benutzerfreundliche Software hinbekommen sondern nur adminfreundliche (AKA "die übliche Linux-Freak-Software". Läuft toll, aber man muss sich erstmal dran gewöhnen und RTFS betreiben).


    SCNR

  • Was ich damit sagen will: Um einen VDR in Betrieb nehmen zu können sollte man kein "Sysadmin" sein müssen.


    Ich empfinde es als großen Vorteil einem Bekannten einfach sagen zu können: Stecke den Tuner einfach rein und boote einmal durch. In denn allermeisten Setups ist die Reihenfolge der Tuner nämlich schnurzpiepegal.

  • Moin!


    Das Konzept "auf feste Anzahl Tuner warten" hatten wir bei yaVDR auch mal, hat sich aber nicht bewährt.
    dynamite arbeitet momentan so, dass es die Adapter-Nummer als CardIndex interpretiert, wenn der CardIndex nicht als udev-Attribut vorgegeben ist. Damit ist adapter0 immer Device 1 usw. Bei Karten mit identischem Treiber wird sich die Reihenfolge der Initialisierung hoffentlich nicht ständig ändern. Bei unterschiedlichen Treibern kann man mit adapter_nr arbeiten, das ist zumindest leichter als eine udev-Regel anzulegen und ließe sich mit irgendeinem Konfigurationsprogramm auch benutzerfreundlich machen.


    Leider haben PCI-Karten so gut wie nie Seriennummern, USB-Karten aber meistens schon. Und bei denen ist eine vorgegebene Nummer viel wichtiger als bei PCI-Karten, weil die Reihenfolge bei USB sich leichter ändern kann als bei PCI.


    Niemand muss ja solche udev-Regeln manuell anlegen. Man könnte, wie oben schon kurz erwähnt, auch ein entsprechendes Progrämmchen schreiben, dass die vorhandenen Karten identifiziert und der Nutzer ordnet einmal die gewünschten Device-Nummern zu. Dann wählt er noch ein passendes udev-Attribut aus, um die Karte wiederzuerkennen (aber nicht DVB_DEVICE_NUM und wie sie heißen...) und dann wird eine entsprechende udev-Regel generiert.


    Aber wir reden hier über Setups mit Device-Bonding oder mehreren Satelliten usw., wo sowas überhaupt eine Rolle spielt. Wer sowas aufbaut, dem kann man auch zutrauen, etwas Doku zu lesen und ein paar Dateien zu editieren. Insbesondere unter Arch... :)
    Womit wir beim wichtigsten sind: egal welche Lösung, sie muss vernünftig dokumentiert werden, dann ist alles kein Problem.


    Lars.

  • Ich habe bei mir gerade mal mit dem attribute-walk gespielt.
    Das ist wirklich ein Problem.


    Aber ist das nicht ein Fehler des Treibers?
    ddbridge z.B. sollte doch exakt wissen, welcher Tuner, wo steckt. Soll doch der Treiber feste Nummern zuordnen. Sonst wird das ja nie wirklich verlässlich.


    CineS2 oberer Port --> Tuner 1
    CineS2 unterer Port --> Tuner 2


    Flex-Modul an Anschluss 1 oberer Port --> Tuner 3
    Flex-Modul an Anschluss 1 unterer Port --> Tuner 4


    Flex-Modul an Anschluss 2 oberer Port --> Tuner 5
    Flex-Modul an Anschluss 2 unterer Port --> Tuner 6


    Flex-Modul an Anschluss 3 oberer Port --> Tuner 7
    Flex-Modul an Anschluss 3 unterer Port --> Tuner 8


    Eine andere Möglichkeit, die ich noch sehe ist es, mein Skript, dass das systemd dropin erstellt zu erweitern.
    Den Tunern feste Nummern zuordnen und dann entsprechend udev-Regeln generieren. Es ist aber schon nicht Sinn der Sache automatisch ein systemd dropin zu generieren und dann udev Regeln?

  • Moin!


    ddbrigde ändert die Reihenfolge der Tuner? Das ist wirklich doof.
    Ich hab UFO auch mal gefragt, ob er nicht die Portnummer o.ä. als udev-Attribut ans Device hängt, dann könnte man jedenfalls zuverlässige udev-Regeln schreiben. Hatte er aber leider bis jetzt keine Zeit/Lust für. Und ich bin immer noch nicht in die Treiberentwicklung eingestiegen, dass ich das mal eben machen könnte...


    Lars.

  • ddbrigde ändert die Reihenfolge der Tuner? Das ist wirklich doof.


    Kann ich nicht sagen. Ich habe nur zwei und ich habe das bisher nicht beobachtet.


    Ich meine damit eigentlich auch was anderes.
    Selbst wenn die Reihenfolge fest ist, ist das nicht zuverlässig.


    Wenn z.B. an Anschluss 1 ein CI-Modul hängt. Schätze ich, dass dann die beiden Tuner an Anschluss zwei zu Tuner 3 und 4 werden.
    Bzw. das ist sicher so, weil ja keine festen Nummern vom Treiber vergeben werden. Wenn an Anschluss 1 etwas anderes, oder nichts hängt werden die Tuner des nächsten Anschlusses (Anschluss 2) nachrücken.
    Steckt man jetzt dort doch Tuner ein (Anschluss 1) passt die Konfiguration wieder nicht mehr.


    Ist das verständlich? Besser kann ichs nicht erklären.

  • Moin!


    Ja, ich verstehe - wenn man was umbaut und Karten mittendrin entfernt/hinzufügt, ändern sich die Nummern für die hinteren Karten.
    Aber das ist durchaus ein Zeitpunkt, an dem man dann die Konfiguration des Systems (vdr usw.) überprüfen und nachjustieren muss.


    Lars.

  • Das ist eine schöne Idee, aber nicht sinnvoll umsetzbar.
    Stell dir vor, du baust neue Karten ein und schmeißt alte raus - dann bist du irgendwann bei Adapter 25-28... :)


    Irgendwann muss man eben mal neu verteilen, Automagie funktioniert immer nur bis zu einem gewissen Punkt.


    Lars.

  • Inwieweit haben sich denn die yaVDR Entwickler mittlerweile in die systemd Thematik eingelesen?
    Das sollte euch ja auch in Kürze betreffen.


    systemd ist ja nicht mehr distributionsspezifisch. Ich würde es daher begrüßen, wenn man zusammen etwas Einheitliches finden könnte.


    Als kleine Diskussionsgrundlage habe ich mal etwas simples angehängt.


    Grundsätzlich fehlen dem VDR zwei Funktionen um für systemd perfekt zu sein.


    1. Der VDR sollte so gut wie keine Parameter über die Kommandozeile erwarten. Ein Service-File zu editieren wegen einem zusätzlichen Plugin, dass geladen werden soll ist meiner Meinung nach unzumutbar.
    --> Im angehängten Tarball über ein kleines Perl-Skript gelöst.


    2. Der VDR sollte auf das erste Device warten und aber auch langsamere Devices noch akzeptieren.
    --> Im Tarball durch ein Shell-Skript gelöst. Dieses wird beim Beenden des VDRs gestartet und erzeugt ein Service-Dropin, das den VDR-Start solange verzögert, bis alle vorher bekannten Devices bereit sind.



    Man könnte/sollte eventuell auch über ein systemd-Plugin für den VDR nachdenken. Ich will die nächsten Tage mal rein interessehalber mal ein paar Gehversuche mit C machen, um den Watchdog von systemd in den VDR zu bekommen.

  • Inwieweit haben sich denn die yaVDR Entwickler mittlerweile in die systemd Thematik eingelesen?
    Das sollte euch ja auch in Kürze betreffen.


    Das brennt noch gar nichts. Trusty wird im April ja noch mit Upstart kommen. Vor Oktober wird sich da wohl wenig tun und ob wir dann wirklich eine nicht LTS-Version benutzen wollen ist mehr als fraglich.

    systemd ist ja nicht mehr distributionsspezifisch. Ich würde es daher begrüßen, wenn man zusammen etwas Einheitliches finden könnte.


    Da bin ich klar deiner Meinung.

    Als kleine Diskussionsgrundlage habe ich mal etwas simples angehängt.


    Da werden wir dich wohl so schnell nicht unterstützen können, siehe oben.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • In meinem Kopf spuken Ideen für zwei Patches.


    Zum einen möchte ich den vdr seine Parameter aus Dateien lesen lassen, ähnlich wie es jetzt schon bei Debian passiert nur direkt im vdr, Plugins soll man dann einfach durch Symlinks o.ä. aktivieren können, am besten gekapselt in ein Tool vdrctl. Und zum anderen möchte ich ihm immer noch "schönes" Hotplug beibringen, dynamite ist ja nur minimal invasiv und eher ein proof-of-concept. Einen Großteil von dynamite (die idle-Geschichte) würde ich wieder entsorgen wollen (vielleicht wird es ja möglich, dafür eine Pluginschnittstelle zu implementieren). In erster Linie geht es mir um das nachträgliche Einbinden von DVB-Devices.
    Aber das wird wohl leider noch ein paar Monate dauern, Freizeit ist momentan knapp.


    Lars

  • Das sollte euch ja auch in Kürze betreffen.

    So in 2 - 6 Jahren, je nachdem wann die Ubuntu-Entwickler soweit sind und es ein LTS Release damit gibt...

    Grundsätzlich fehlen dem VDR zwei Funktionen um für systemd perfekt zu sein.

    Mir fallen da noch ein paar mehr ein, z.B. Unterstützung für systemd-notify, Setzen von Shutdown-Inhibitoren usw.

    1. Der VDR sollte so gut wie keine Parameter über die Kommandozeile erwarten. Ein Service-File zu editieren wegen einem zusätzlichen Plugin, dass geladen werden soll ist meiner Meinung nach unzumutbar.
    --> Im angehängten Tarball über ein kleines Perl-Skript gelöst.

    Ich weiß nicht, ob der Umweg über ein zusätzliches Start-Skript dem User wirklich etwas bringt - eigentlich reicht ja eine einfaches EnvironmentFile (das kann die Distrubution ja immer noch über ein Skript wie das von mini73 vorgeschlagene vdrctl generieren, wenn es gewünscht ist):


    2. Der VDR sollte auf das erste Device warten und aber auch langsamere Devices noch akzeptieren.
    --> Im Tarball durch ein Shell-Skript gelöst. Dieses wird beim Beenden des VDRs gestartet und erzeugt ein Service-Dropin, das den VDR-Start solange verzögert, bis alle vorher bekannten Devices bereit sind.

    Vergiss die udev-Regel nicht, damit die DVB-Geräte den systemd-Tag verpasst bekommen :)
    Je nach Situation macht es mehr oder weniger Sinn das zu benutzen (für einen reinen streamdev-client ist z.B. nur eine vorhandene Netzwerkverbindung wichtig) - vielleicht wäre es sinnvoll das und z.B. auch Type=notify wenn dbus2vdr mit --systemd geladen wird oder das Binden eines tty an den VDR, wie es z.B. für den Raspberry Pi und FF-Karten-Besitzer Sinn machen kann über solche Service-Dropins zur Verfügung zu stellen, die man bei Bedarf scharfschalten kann, indem man sie an die richtige Stelle kopiert oder verlinkt.

    Code
    1. [Service]
    2. ExecStartPre=/usr/bin/chvt 2
    3. StandardInput=tty-force
    4. TTYPath=/dev/tty2
    5. TTYVHangup=yes


    Man könnte/sollte eventuell auch über ein systemd-Plugin für den VDR nachdenken. Ich will die nächsten Tage mal rein interessehalber mal ein paar Gehversuche mit C machen, um den Watchdog von systemd in den VDR zu bekommen.

    Gute Idee, dbus2vdr kann ja schon den Start des VDR-Mainloop über systemd-notify anzeigen - das wäre eventuell auch etwas für das Plugin.


    Ich weiß nicht, ob man sich da auf einen Standard einigen kann (und ob es überhaupt Sinn macht) - schließlich gilt es oft sehr individuelle Probleme zu lösen und es gibt schon unterschiedliche Ansätze in freier Wildbahn und jeder scheint ein bisschen andere Vorstellungen davon zu haben wie er die Probleme angeht (runvdr nutzen, EnvironmentFile kurz vor dem Start erzeugen, Setzen des Aufwachzeitpunkts außerhalb eines Shutdown-Skripts usw.)

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    The post was edited 1 time, last by seahawk1986 ().

  • Ich weiß nicht, ob der Umweg über ein zusätzliches Start-Skript dem User wirklich etwas bringt - eigentlich reicht ja eine einfaches EnvironmentFile (das kann die Distrubution ja immer noch über ein Skript wie das von mini73 vorgeschlagene vdrctl generieren, wenn es gewünscht ist):

    Wie gesagt: Diskussiongrundlage :P
    Wenn ich jetzt aber mal ein so schön aufgeräumtes EnvironmentFile sehe, finde ich das auch eine gute Lösung.


    Vergiss die udev-Regel nicht, damit die DVB-Geräte den systemd-Tag verpasst bekommen :)

    Jaaa. Die unterschlage ich irgendwie jedes Mal. Ich sollte auch noch dazusagen, dass das gensddropin Skript nicht mit den Sundtek-Sticks funktioniert. systemd sieht die Sundtek Devices nicht und das führt dann dazu dass der VDR mit 90sec Verspätung (Timeout) startet.


    Je nach Situation macht es mehr oder weniger Sinn das zu benutzen (für einen reinen streamdev-client ist z.B. nur eine vorhandene Netzwerkverbindung wichtig) - vielleicht wäre es sinnvoll das und z.B. auch Type=notify wenn dbus2vdr mit --systemd geladen wird oder das Binden eines tty an den VDR, wie es z.B. für den Raspberry Pi und FF-Karten-Besitzer Sinn machen kann über solche Service-Dropins zur Verfügung zu stellen, die man bei Bedarf scharfschalten kann, indem man sie an die richtige Stelle kopiert oder verlinkt

    Kann ich gerne vorbereiten. Vorhandene Netzwerkverbindung ist so eine Sache. Ich hoffe da im moment auf das gerade entstehende systemd-networkd. Das sollte in dieser Hinsicht einiges einfacher machen.


    Gute Idee, dbus2vdr kann ja schon den Start des VDR-Mainloop über systemd-notify anzeigen - das wäre eventuell auch etwas für das Plugin.

    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.


    schließlich gilt es oft sehr individuelle Probleme zu lösen und es gibt schon unterschiedliche Ansätze in freier Wildbahn und jeder scheint ein bisschen andere Vorstellungen davon zu haben wie er die Probleme angeht (runvdr nutzen, EnvironmentFile kurz vor dem Start erzeugen, Setzen des Aufwachzeitpunkts außerhalb eines Shutdown-Skripts usw.)

    Das gilt es hier herauszufinden.
    runvdr erinnert mich eher an das alte sysvinit.
    EnvironmentFile kurz vor dem Start erzeugen ist zwar möglich (ExecStartPre), aber nicht so ganz erwünscht --> http://lists.freedesktop.org/a…/2012-October/007289.html
    Das kleine Perl-Skript ist mehr oder weniger die Umsetzung der obigen Mail von Lennart Poettering.


  • Zum einen möchte ich den vdr seine Parameter aus Dateien lesen lassen, ähnlich wie es jetzt schon bei Debian passiert nur direkt im vdr, Plugins soll man dann einfach durch Symlinks o.ä. aktivieren können, am besten gekapselt in ein Tool vdrctl. Und zum anderen möchte ich ihm immer noch "schönes" Hotplug beibringen, dynamite ist ja nur minimal invasiv und eher ein proof-of-concept. Einen Großteil von dynamite (die idle-Geschichte) würde ich wieder entsorgen wollen (vielleicht wird es ja möglich, dafür eine Pluginschnittstelle zu implementieren). In erster Linie geht es mir um das nachträgliche Einbinden von DVB-Devices.
    Aber das wird wohl leider noch ein paar Monate dauern, Freizeit ist momentan knapp.


    Sei so gut und stimme das vorher mit Klaus ab. Ich weiß zumindest (weil ich mich da selber schon dran versuchen wollte), dass Klaus der Idee mit den Konfigurationsdateien generell nicht negativ gegenübersteht. Er hat aber sehr genaue Vorstellungen wie die Konfig-Dateien auszusehen haben. Ich habe das nach etlichen Stunden Gebastel verworfen. Irgendwie stehe ich mit C(++) auf Kriegsfuß.


    Mittlerweile bin ich mir aber auch garnicht mehr so sicher ob ich das überhaupt im VDR direkt haben möchte. Flexibler ist man mit einem Script davor. Dann könnte man das Zusammenladen der Konfiguration und ggf. auch der Usermode-Tools unabhängig vom VDR selbst weiterentwickeln und ausbauen. Zumindest war das mein Gedanke und ich habe auch sowas wie "vdrctl" zum aktivieren/deaktivieren von Plugins im Sinn. Dabei würde ich eine "vdr.conf" als globale Datei vorsehen wollen und dann weitere aus einem "conf.d"-Verzeichnis dann einer gewissen Nummerierung folgend dazuladen. So könnte man dann die Plugin-Configs sauber integrieren und via Symlinks auch Plugins aktivieren/deaktivieren. Wenn dann letztlich die Befehlszeile fertig ist, dann den VDR via "exec" anstarten --> Script terminiert komplett und gibt seine PID an den VDR-Prozess weiter.


    Wenn ich wüsste, dass die Arbeit nicht für'n Fuß ist, dann würde ich mich da mal dran versuchen.


    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.