[Aus der ML] New conf.d support + ONEDIR option. Need opinions

Zitat von kls

Falls kein Widerspruch kommt werde ich das noch für die Version 2.1.8 einbauen, die ich kommenden Sonntag freigeben möchte.

Das ist doch mal ein schöner Releasezyklus. Den solltest du beibehalten.

Ich finde, da spricht nichts gegen. ONEDIR sollte auch ONEDIR sein.

Lars

Von mir aus auch nicht.

Aber wenn wir gerade dabei sind, wie genau funktioniert das mit den *.conf Dateien?

Kann ich da beispielsweise eine plugin.satip.conf anglegen mit

-P'satip -d2'

So klappte das bei mir nicht. Oder hab ich das falsch verstanden?

Auf diese Art und Weise:
https://github.com/VDR4Arch/vd…s/vdr-satip/50-satip.conf

Zitat von olebowle

Auf diese Art und Weise:
https://github.com/VDR4Arch/vd…s/vdr-satip/50-satip.conf

Danke

So richtig klappts noch nicht. Aber da muss ich nochmal die manpages durchforsten. Im Moment seh ich nur im Log:

Jan 30 00:03:27 homeserver vdr: [19209] exiting, exit code 2
Jan 30 00:03:27 homeserver vdr: [19210] ERROR (tools.c,406): ???#001: Datei oder Verzeichnis nicht gefunden

vdr --showargs sollte beim debuggen helfen. Die *.conf Dateien werden in /etc/vdr/conf.d erwartet.

Zitat von olebowle

vdr --showargs sollte beim debuggen helfen. Die *.conf Dateien werden in /etc/vdr/conf.d erwartet.

Das ist mir bewusst, dass die nach /etc/vdr/conf.d gehören. Dort liegen die auch. Eventuell hab ich ja noch irgendwo einen Schreibfehler drin, das muss ich mir mal anschauen.

vdr --showargs
--plugin=satip --devices=2
--plugin=epg2vdr
--plugin=epgsearch
--plugin=live --ip=192.168.1.2 --port=8008 --epgimages=/var/cache/vdr/epgimages
--plugin=scraper2vdr --mode=headless
--plugin=femon
--plugin=streamdev-server
--plugin=vnsiserver -t 10

Braucht der vdr dann zwingend [vdr] im conf.d Verzeichnis? Hatte das bisher nur für die Plugins umgesetzt. Ein kurzer Test mit einer vdr.conf und [vdr]-Abschnitt zeigte, dass man keine Environment Variablen nutzen kann, korrekt? Bei mir werden die Einstellungen aus /etc/default/vdr geholt.

Ohne eine Datei mit "[vdr]" kannst du halt keine VDR-Parameter angeben.

Und nein: Umgebungsvariablen gehen hier nicht.

Eben das war sicher das Problem. Hatte nur die Plugins aus meiner runvdr gelöscht und dafür .conf files angelegt. Die VDR-Args weiterhin in der runvdr angegeben.

Es müssen alle Argumente in die conf.d-Dateien.
Ich wollte noch mal ein bisschen Doku dazu schreiben, bin aber noch nicht dazu gekommen.

Lars.

Ja, das ist mir nun auch bewusst. Die Unterstützung von Umgebungsvariablen wäre noch schön, oder macht das keinen Sinn?

Ziel ist es, dass man dann einfach durch Start von "vdr" den vdr mit allen Parametern, die man so haben möchte, starten kann. Hauptanwendungszweck sind die modernen Init-Systeme wie systemd und upstart, die wesentlich übersichtlicher in ihren unit- bzw. job-Dateien werden, wenn da einfach nur eine "exec"-Zeile drin steht. Außerdem kann man dann ein zur Distribution passendes Init-Script mitliefern, die Konfiguration kann man dann aber unter /etc/vdr/conf.d ablegen.

Besser noch liegen die Dateien (eine für den vdr und jeweils eine pro Plugin) in /etc/vdr/conf.avail und werden dann per symlink nach ../conf.d verlinkt. Durch Setzen/Löschen eines Links kann man dann Plugins aktivieren/deaktiveren.

Man kann sich auch mehrere Verzeichnisse mit unterschiedlichen Konfigurationen zusammenstellen, die man dann komplett als conf.d verlinkt. Da ist vieles möglich. Das muss aber erst so langsam in die Distributionen wandern, das wird sicherlich eine Weile dauern.

Die ganzen Scripte unter Debian sind schon ganz schön und nett, aber wenn man sich mal so ansieht, wie viele da für einen einfachen vdr-Start abgearbeitet werden... Das geht jetzt "schöner".

Was möchtest du denn über Umgebungsvariablen setzen? Was soll damit angepasst werden?

Lars.

Ich benutze ja nicht die Standard-Debian-Skripte, sondern kompiliere selbst und bastel mir auch die Startskripte selbst.

Nach Umstellung auf systemd hatte ich mir runvdr und vdr.service so umgebaut, dass die Parameter auf /etc/default/vdr gelesen werden:

Der Inhalt sah dann so aus

RESDIR=/etc/vdr/ 
GRABDIR=/tmp 
USER=root
CONFIGDIR=/etc/vdr
VIDEODIR=/volume1/vdr
EPGFILE=/var/cache/vdr/epg.data
LIBDIR=/usr/local/lib/vdr
SHUTDOWNSCRIPT=/usr/local/bin/vdrwakealarm2
RECORDINGACTION=/usr/local/bin/recordingaction

und vdr.service so:

[Unit]
Description=VDR
After=network.target


[Service]
Type=forking
EnvironmentFile=/etc/default/vdr
ExecStart=/usr/local/bin/runvdr_new
Restart=on-failure


[Install]
WantedBy=multi-user.target

Aber hast recht, könnte natürlich die vdr.conf einfach per Symlink nach /etc/default verlinken. Die runvdr fällt ja dann weg.

Genau, Ziel ist es, die runvdr nicht mehr zu benötigen. Bei ExecStart sollte man dann direkt den vdr eintragen können und das EnvironmentFile nur für solche Dinge benutzen, die der vdr über Umgebungsvariablen macht (CHARSET_OVERRIDE usw.).
Also statt der Umgebungsvariablen eine /etc/vdr/conf.d/vdr.conf anlegen, in der die Parameter direkt drinstehen. Das muss man ja nicht mit Umgebungsvariablen machen.

Lars.

Der Vorteil ist dann, dass die conf-Dateien von jedem gelesen werden können, weil es die Standard-vdr-Parameter sind. Dann muss man sich nicht erst durch Scripte wühlen, um zu sehen, wo welche Umgebungsvariable wie benutzt wird.

Lars.

OK, verstanden.

Noch eine Frage dazu, weil das ja für systemd benötigt wird. Im VDR Code gibts ja:

#ifdef SDNOTIFY
  sd_notify(0, "READY=1\nSTATUS=Ready");
#endif

Auch im Makefile gibts solche ifdefs.

Muss ich das im Makefile irgendwo angeben, damit das aktiv ist? SDNOTIFY=1 in Make.config? Oder kommt das aus irgendeinem include?

Du benötigst es nicht. Nur wenn du ein Service-File mit Type=notify haben willst. Es ist aber natürlich praktisch für Dienste, die auf den VDR warten wollen/müssen.

SDNOTIFY = 1 ist richtig

Zitat von Copperhead

Du benötigst es nicht. Nur wenn du ein Service-File mit Type=notify haben willst. Es ist aber natürlich praktisch für Dienste, die auf den VDR warten wollen/müssen.

SDNOTIFY = 1 ist richtig

Ich baus mal mit ein, sonst ging es mit simple nicht.

Zitat

Behavior of notify is similar to simple; however, it is expected that the daemon sends a notification message via sd_notify(3) or an equivalent call when it has finished starting up.

EDIT: Jetzt tut es auch, wie es soll.

Das einzige Problem, was aber bleibt: Man benötigt so ein Skript: https://github.com/VDR4Arch/vd…b/master/vdr/gen-sddropin

Dieses Skript läuft bei VDR4Arch beim Beenden des VDRs und speichert die bekannten DVB-Devices, damit systemd den VDR erst startet, nachdem diese Devices wieder initialisiert sind.