systemd: vdr.service

obarden · 15. Mai 2012

OK, Dank Ausschlussverfahren hab ich den Verursacher gefunden.
Ich hab im runvdr.conf DAEMON=1 stehen gehabt, nachdem das draußen war lädt es nun auch über systemd.
Was für Konsequenzen hat das wenn vdr nicht als daemon läuft ??

mini73 · 15. Mai 2012

Moin!

Bei systemd ist es sinnvoller sogar gewollt, das Programme nicht als Daemon laufen zu lassen.
Einfach mal die Serie zu systemd von Lennart Poettering lesen.

Lars.

cooljay032 · 28. November 2012

moin zusammen,

da die arch-jungs ja mittlerweile voll auf systemd abfahren bin ich auch grade dabei mein vdr entsprechend umzubauen. bis auf vdr auf kein problem soweit.
aber "quick+dirty" die runvdr aufrufen klappt bei mir nicht, es fehlen sämtliche kommandozeilenparameter wie plugins, usw.
ich möchte mir aber auch kein "hardcoded" servicefile basteln wo alles manuell eingetragen werden muss...
hat da vielleicht jemand noch was (für mich) brauchbares in petto

gruß,lars

M-Reimer · 28. November 2012

runvdr-extreme? Bietet recht brauchbare Vorkonfiguration der vielen VDR-Paramter und Plugin-Parameter in Form einer Config-Datei. Muss aber für korrekte Funktion mittlerweile gepatcht werden. Patches hänge ich bei Bedarf der Übersicht halber aber ggf. nochmal hier an.

M-Reimer · 28. November 2012

Zitat von mini73

Moin!

Bei systemd ist es sinnvoller sogar gewollt, das Programme nicht als Daemon laufen zu lassen.
Einfach mal die Serie zu systemd von Lennart Poettering lesen.

Lars.

Bitte einen Link dazu posten. Danke.

cooljay032 · 28. November 2012

Zitat von Mreimer

runvdr-extreme

hatte ich mir auch schon mal angekuckt, wäre evtl. n versuch wert. obwohl mir das eintragen der plugins inkl. parameter in ner separaten konfig auch nicht so gefallen will, aber gut.

Zitat von Mreimer

Muss aber für korrekte Funktion mittlerweile gepatcht werden

aha, dann nehme ich an die hier https://aur.archlinux.org/packages/runvdr-extreme/ funzt nicht mehr ootb!? oder ist der patch "runvdr-extreme-0.4.2.patch" der dabei ist der den du meinst?

Zitat

Bitte einen Link dazu posten. Danke.

ich denke mal lars meinte das hier http://0pointer.de/blog/projects/systemd.html

cooljay032 · 28. November 2012

so,läuft mittlerweile mit aufruf runvdr-extreme im service,nice
so long,lars

olebowle · 28. November 2012

Also bei mir sieht die vdr.service unter Archlinux wie folgt aus:

Code

[Unit]
Description=Video Disk Recorder
After=lirc.service dev-dvb-adapter0-frontend0.device
Wants=lirc.service dev-dvb-adapter0-frontend0.device


[Service]
PIDFile=/run/runvdr.pid
ExecStart=/etc/rc.d/vdr start
ExecReload=/etc/rc.d/vdr restart
ExecStop=/etc/rc.d/vdr stop


[Install]
WantedBy=multi-user.target

Alles anzeigen

Dazu noch folgende udev-Regel:

Code

SUBSYSTEM=="video4linux", TAG+="systemd"
SUBSYSTEM=="dvb", TAG+="systemd"

Und es tut, wie es soll.

Copperhead · 14. April 2013

Ich grabe das hier mal wieder aus...

Wie groß ist denn das Interesse an einem Service-File, dass für alle systemd basierten Systeme passt?
Ich beschäftige mich jetzt seit ein paar Tagen damit eine vdr.service Datei für vdr4arch anzulegen. Probleme macht mir hauptsächlich die Kommandozeile für den VDR zusammenzusetzen.

Die Plugins müssen irgendwo übersichtlich definiert werden, entweder irgendwie über ein service.d File, oder alle zusammen in einem EnvironmentFile. Dazu ist mir aber noch keine hübsche Syntax eingefallen.

Im Moment benutze ich runvdr-extreme, welche alles in allem nett ist, aber nicht mehr zeitgemäß. Viele Aufgaben können direkt von systemd übernommen werden. Andere Aufgaben werden gar nicht in Betracht gezogen, da diese erst du eventbasierte Init-Systeme entstande sind. (VDR startet bevor DVB-Devices bereits sind)

Ich denke mal, dass der VDR nie eine eigene Config für die Startparameter haben wird, daher wird man nicht um ein Skript drumherum kommen. Das wäre nämlich meine bevorzugte Methode und das würde sich auch mit den Vorgaben für systemd decken.

Ich würde das Skript auch schreiben.

Auf der TODO-Liste wäre.
Das Lesen einer Config-Datei und das Zusammensetzen der Parameter implementieren
Shutdown inklusive ACPI-Wakeup implementieren
Eventuell beim Shutdown die DVB-Devices prüfen und entsprechend Warteregeln für systemd erstellen.

Ich hoffe jetzt einfach mal auf ein bisschen Feedback und Anregungen.

FireFly · 14. April 2013

Zitat von Copperhead

Wie groß ist denn das Interesse an einem Service-File, dass für alle systemd basierten Systeme passt?

Interesse hätte ich schon, aber bisher nutzen scheinbar alle Distris die runvdr in der einen oder anderen Form wie z.B. extreme-runvdr. Eine vdr.service, die die Features von systemd nutzt, habe ich bisher noch nicht gefunden (außer man kodiert die ganzen Plugins und Parameter hart in vdr.service).
Gibt es bei systemd überhaupt die Möglichkeit Startparameter aus einer Datei zu lesen und wie machen das die ganzen anderen Services?

Copperhead · 14. April 2013

Startparameter lassen sich durch sogenannte EnvironmentFiles definieren. Da gibt es aber das Problem, dass jeder Variable nur einmal definiert werden kann. Ich habe es bisher nicht geschafft Arrays aufzubauen, die dann auch funktioniert haben.

Bzw. dort kann man Variablen definieren, die dann zum zusammenstückeln der Startparameter genutzt werden können.
Das ist eigentlich die Hauptmöglichkeit. Die meisten anderen Daemons haben den Anforderungen nachgegeben und lesen jetzt entsprechend selbstständig Konfigdateien ein.

Lennart Pöttering schägt für Daemons, die das nicht können und komplizierte Startparameter benötigen ein Zusatzskript vor, das dann eine Konfigdatei liest.

domml · 14. April 2013

Für die Plugin-Parameternhat SuSE eine ganz hübsche Lösung:
ein Environment-Variable mit der Liste der Plugins.
je eine Environment-Variable je Plugin, die die Muster
XXX_pluginname gehorcht und dann per Script ausgewertet wird.

Das wird dann auch nicht ohne Script abgehen, aber ich finde es ist ganz praktisch.

Für die häufigsten vdr-Parameter gibt's dann auch Env-Variablen.

Viele Grüße

Dominik

Gesendet von meinem iPad mit Tapatalk HD

seahawk1986 · 14. April 2013

Zitat von domml

Für die Plugin-Parameternhat SuSE eine ganz hübsche Lösung:
ein Environment-Variable mit der Liste der Plugins.
je eine Environment-Variable je Plugin, die die Muster
XXX_pluginname gehorcht und dann per Script ausgewertet wird.

Das wird dann auch nicht ohne Script abgehen, aber ich finde es ist ganz praktisch.

Hast du einen Link, damit ich mir das mal ansehen kann?

Copperhead · 14. April 2013

Wollte ich auch gerade fragen...

Ich kenne wie gesagt nur runvdr-extreme

Code

AddPlugin softhddevice
AddPlugin live
AddPlugin epgsearch

und Fedora

Code

VDR_PLUGIN_ORDER="
softhddevice
live
epgsearch
"

Mir persönlich gefällt die Syntax von runvdr-extreme am besten.

seahawk1986 · 14. April 2013

Zitat von Copperhead

Das Lesen einer Config-Datei und das Zusammensetzen der Parameter implementieren

Da hänge ich aktuell auch dran, denn Systemd kann soweit ich es verstanden habe die Umgebungsvariablen leider nicht direkt aus dem stdout eines Skriptes lesen.

Zitat von Copperhead

Lennart Pöttering schägt für Daemons, die das nicht können und komplizierte Startparameter benötigen ein Zusatzskript vor, das dann eine Konfigdatei liest.

Ist das dann ein Wrapper-Skript, das dann wie die runvdr-extreme den VDR startet oder kann das Zusatzskript tatsächlich innerhalb eines systemd-Services die Umgebungsvariablen einlesen?

Als ultimative systemd-Rube-Goldberg Lösung könnte man analog zum Automatischen Datei-Update für UEFI über systemd (das in https://wiki.archlinux.org/ind…oaders#Systemd_Automation beschrieben wird) eine "komfortable" Konfigurationsdatei bei Änderungen direkt über ein Skript in das gewünschte Zielformat überführen lassen, so dass es als EnvironmentFile genutzt werden kann

/usr/lib/systemd/system/vdrconfig_update.path

Code

[Unit]
Description=Update vdr user configuration files


[Path]
PathChanged=/etc/vdr.conf
Unit=vdrconfig_update.service


[Install]
WantedBy=multi-user.target

Alles anzeigen

/usr/lib/systemd/system/vdrconfig_update.service

Code

[Unit]
Description=Update vdr user configuration files


[Service]
Type=oneshot
ExecStart=/usr/bin/update_vdrconfig
RemainAfterExit=no

Und dann noch aktivieren:

Code

systemctl enable vdrconfig_update.path

Für die Plugins hatte ich mir schon mal etwas überlegt, das die Pluginparameter für den VDR liefert, die Startargumente für den VDR und das Erstellen des EnvironmentFiles fehlen noch:

Python

#!/usr/bin/python3


import configparser


class Config:
    def __init__(self, config='/etc/vdr.conf'):
        self.parser = configparser.SafeConfigParser(allow_no_value=True, delimiters=(" ",":","="))
        with open(config, 'r', encoding='utf-8') as f:
            self.parser.readfp(f)


    def get_plugins(self):
        self.plugins = []
        if self.parser.has_section('Plugins'):
            for plugin, args in self.parser.items('Plugins'):
                if len(args) == 0:
                    self.plugins.append('-P %s' % plugin)
                else:
                    self.plugins.append(('-P "%s %s"' % (plugin, args)))
            return " ".join(self.plugins)
        else:
            return ""


if __name__ == '__main__':
    print(Config().get_plugins())

Alles anzeigen

/etc/vdr.conf

Code

[Plugins]
softhddevice -w still-h264-hw-decoder -v vdpau
skinnopacity --epgimages=/var/cache/vdr/epgimages/
live -i 0.0.0.0 -p 8008 --epgimages=/var/cache/vdr/epgimages
#skinenigmang
# usw.

Copperhead · 14. April 2013

Baaah, python. *kreisch*

Falls ich das später maintainen soll, würde ich das in Perl neuschreiben. Python ist nicht meine Sprache. Die Syntax der Config gefällt mir aber.

BTW: Man kann mit ExecStartPre ein Environment-File generieren, dass dann bei ExecStart wirkt.

FireFly · 14. April 2013

Zitat von domml

Für die Plugin-Parameternhat SuSE eine ganz hübsche Lösung:
ein Environment-Variable mit der Liste der Plugins.
je eine Environment-Variable je Plugin, die die Muster
XXX_pluginname gehorcht und dann per Script ausgewertet wird.

Das wird dann auch nicht ohne Script abgehen, aber ich finde es ist ganz praktisch.

Für die häufigsten vdr-Parameter gibt's dann auch Env-Variablen.

Ich glaube er meint folgendes (nutze ich auch), was aber an der Fragestellung mit systemd vorbei geht:

Code

in /etc/sysconfig/vdr:
VDR_PLUGINS="softhddevice osdteletext dvbhddevice burn avards skinelchi"


VDR_PLUGIN_ARGS_burn="-D /dev/sr0  -i /tmp"
#VDR_PLUGIN_ARGS_avards="-g"
VDR_PLUGIN_ARGS_osdteletext="-d/vdr/teletext"
VDR_PLUGIN_ARGS_skinelchi="-l /etc/vdr/plugins/skinelchi -c /tmp/epgimages"
VDR_ADDITIONAL_ARGS="-E /vdr/epg.data"

Das wird dann vom Startskript zur Kommandozeile zusammen gesetzt:

Code

/usr/bin/vdr -c /etc/vdr   "-Pavards"  "-Pburn -D /dev/sr0 -i /tmp" "-Posdteletext -d/vdr/teletext" "-Pskinelchi -l /etc/vdr/plugins/skinelchi -c /tmp/epgimages -E /vdr/epg.data"

Das Problem ist, dass ein Skript das erst alles zusammenbauen muss was bei Suse in der /usr/sbin/runvdr passiert, die wir ja eliminieren wollen. FAlls man das als ExecStartPre angebeben könnte und anschließend ein generiertes EnvironmentFile einlesen könnte hätte man ne Chance, sofern systemd sich an die Reihenfolge hält ...

seahawk1986 · 14. April 2013

Zitat von FireFly

Alls man das als ExecStartPre angebeben könnte und anschließend ein generiertes EnvironmentFile einlesen könnte hätte man ne Chance, sofern systemd sich an die Reihenfolge hält ...

Ich würde das EnvironmentFile lieber direkt nachdem die Konfigurationsdatei geändert wurde generieren und nicht jedes mal beim Start des VDR neu zusammensetzen lassen, sonst hat es ja kaum Vorteile wenn man das Wrapper-Skript abzuschafft.
Die Konfigurationsdatei von SuSE gefällt mir so auf den ersten Blick nicht so wirklich, das ist ja schon fast mehr Arbeit die zu pflegen als direkt die Argumente zusammenzuschreiben...

Zitat von Copperhead

Baaah, python. *kreisch*

Immerhin ist es im Gegensatz zu Perl keine esotherische Programmiersprache

Copperhead · 14. April 2013

Letztlich ist die Sprache ja egal. Derjenige der es pflegt nimmt einfach die Sprache die ihm am besten liegt.

Automatisch ein EnvironmentFile generieren scheint nicht gewünscht zu sein. Hier mal eine Mail von Lennart Pöttering.
http://lists.freedesktop.org/a…/2012-October/007289.html

seahawk1986 · 14. April 2013

Zitat von Copperhead

Automatisch ein EnvironmentFile generieren scheint nicht gewünscht zu sein. Hier mal eine Mail von Lennart Pöttering.

Zumindest innerhalb eines Service im Rahmen eines ExecStartPre, von außerhalb hat er nichts geschrieben

Generell bin ich mir da noch nicht sicher wie nahe man da z.B. auch für den Start des X-Servers an den Empfehlungen bleiben sollte - wenn ich das aus dem Arch-Wiki richtig herausgelesen habe wäre das ja eigentlich potentiell eine Sache für eine systemd-User-Session, in der dann alles weitere für den Benutzer vdr gestartet wird - was aber für ein schlankes Einzelbenutzersystem nicht zwangsläufig das Optimum wäre und die ganze Konfiguration im vergleich zum jetzigen Stand wesentlich komplexer gestalten würde...

systemd: vdr.service

Jetzt mitmachen!

Teilen

Tags