[Gelöst} Sundtek.service - systemd - Wer kennt sich mit .service (etc.) files aus

Forkt der "Sundtek-Treiber" erst, wenn die Devices auch wirklich verfügbar sind? Irgendein Merkmal brauchst du ja schließlich um festzustellen ob der VDR nun gestartet werden darf?

Zitat von Atechsystem

Ich weiss leider nicht wie ich das über die service files steuern kann. Ausserdem finde ich auch keine brauchbare Erläuterung der Möglichkeiten von service Dateien.

Die schönste Lösung wäre das dynamite-Plugin - damit werden DVB-Geräte eingehängt, sobald sie zur Verfügung stehen und man darf sie im laufenden Betrieb an- und abstecken. Falls das nicht möglich ist (z.B. weil es sich mit einem anderen benötigten Plugin oder der Konfiguration beißt), könntest du darauf warten, dass der Adapter angelegt wird (und falls das nicht innerhalb von OnActiveSec passiert den Dienst trotzdem starten lassen) - so ähnlich wurde es hier als funktionierende Lösung gepostet: http://lists.fedoraproject.org…/2012-January/160910.html

[Unit]
Description=Video Disk Recorder
After=lirc.service 
After=sundtek.service
Wants=lirc.service
Wants=sundtek.service


[Service]
ExecStart=/usr/bin/runvdr
KillMode=process


[Path]
PathExists=/dev/dvb/adapter1/frontend0
PathExists=/dev/dvb/adapter1/demux0


[Timer]
OnActiveSec=120


[Install]
WantedBy=multi-user.target

Die Lösung mit der Pfadprüfung ist interessant...

Allerdings frage ich mich dennoch ob dieser Sundtek-Daemon erst dann forkt wenn *alle* Devices da sind. Die Pfadprüfung prüft ja nur auf *ein* Device. Wenn es derer mehrere gibt, dann startet der VDR dann doch unter Umständen zu früh?

Zitat von Atechsystem

genau da liegt mein Problem. Im grunde wird ja durch das Servicefile nur der Start angetriggert. Ich gehe davon aus, dass es dann als "active" markiert wird und eben nich abgewartet wird bis der Treiber komplett geladen ist. Daher meine Frage ob es mit den service Dateien alleine überhaupt möglich ist soetwas zu realisieren.

"type=Forking" ist eine mögliche Art wie man systemd mitteilen kann wann der betroffene Dienst "bereit" ist. Er darf dann aber erst forken wenn auch wirklich alles betriebsbereit ist.

Zitat

1.) Sundtek Stick laden - warten bis er bereit ist
2.) VDR laden - warten bis er bereit ist
3.) X starten
4.) Wenn X gestartet Softhddevice per SVDRP ATTA anbinden

Eigentlich kann 2. und 3. parallel erfolgen - dann müsste aber das verbinden von Softhddev sicherstellen, dass der xserver geladen wurde und der VDR auch schon getstartet hat.

Alles anzeigen

Softhddevice ist fähig den X-Server auch komplett selber mitzustarten. Alternativ: runvdr-extreme nehmen und den VDR und den X-Server damit starten. Eine zentrale Konfiguration für Plugin- und VDR-Paramter gibt's da gleich gratis mit dazu.

Allerdings musst du die runvdr-extreme patchen. Es gibt da einige Fehler die sonst einen stabilen Betrieb verhindern:

https://github.com/CReimer/vdr…ree/master/runvdr-extreme

Mal ne ganz provokante Idee Wie wäre es damit einfach mal Sundtek zu fragen woran man erkennt das der Daemon bereit ist? Die werden wissen wie der Daemon funktioniert
Das /dev/dvb/adapter1/frontend0 existiert muss ja nicht zwangsläufig bedeuten das es auch schon funktioniert. Und es muss ja auch nicht zwangsläufig bedeuten das es zum Sundtek Daemon gehört.

Die von Sundtek sind doch hier, und so wie ich das sehe sind die auch immer hilfsbereit. Da würde ich doch einfach mal fragen bevor ich rumbastele und irgendwelche halbgaren würgarounds hinfummle.

BTW: Das Problem besteht ja nicht nur bei systemd, upstart und sysvinit haben ja das selbe Problem. Und das ist ja nicht nen reines Sundtek Problem, auch dieses Problem stößt man bei jeden Daemon den man starten will.
Z.B. fehlt hier auch noch beim VDR Start die Erkennung wann der VDR bereit ist, das dbus2vdr Plugin hat da z.B. extra was drin damit Upstart erkennen kann wann der VDR wirklich fertig gestartet ist (d.h. der VDR wirklich bereit ist).

cu

Zitat von Atechsystem

Hallo Portal,
Es gibt zwar die Möglichkeit im Sundtek Treiber nach dessen Initialisierung ein Programm und somit auch den VDR zu starten, aber das würde dazu führen wenn der Stick nicht gestartet werden kann startet auch der VDR nicht. Aufnahmen könnten auf der zweiten Karte dann nicht durchgeführt werden.

Code

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


#dev-dvb-adapter0-frontend0.device dev-dvb-adapter1-frontend0.device


[Service]
ExecStart=/usr/bin/vdr -v "/var/lib/video.00" -c "/var/lib/vdr" -L "/usr/lib/vdr/plugins" -r "/usr/lib/vdr/vdr-recordingaction" -s >(usw.)<
Restart=on-failure


[Install]
WantedBy=multi-user.target

Alles anzeigen

Sundtek
[code]
[Unit]
Description=Sundtek MediaTV Pro driver
Before=lirc.service

[Service]
Type=forking
ExecStart=/opt/bin/mediasrv -d --pluginpath=/opt/bin
ExecStop=/opt/bin/mediaclient --shutdown

Alles anzeigen

Du kannst --wait-for-devices beim Daemon anhängen, falls ein Gerät angeschlossen ist wird dieses vollkommen initialisiert bevor sich mediasrv in den Background katapultiert. Falls kein Gerät angeschlossen ist geht es an der Stelle auch sofort weiter.
Bin jetzt nicht so belesen in den Service files, aber Type=forking dürfte dann ja nicht richtig sein da es wohl nicht blockieren würde (eventuell Type=simple ?).

"forking" ist dann schon richtig. Bei "simple" wird erwartet, dass der Daemon nicht forkt, also durchläuft. Wenn er doch forkt (also der erste gestartete Prozess terminiert), dann gilt der Prozess bei "simple" als "nicht laufend".

Zitat von Atechsystem

Jetzt muss ich nur noch hinbekommen, dass softhddevice sich vernünftig verbindet. Ich werde mal dbus2vdr anschauen.

Wenn der X-Server bereits läuft, dann verbindet sich softhddevice direkt und ohne manuelles "Attachen". Versuche halt bei Gelegenheit mal runvdr-extreme und wenn du damit Probleme hast, dann melde dich nochmal.

Moin!

Zitat von Keine_Ahnung

Z.B. fehlt hier auch noch beim VDR Start die Erkennung wann der VDR bereit ist, das dbus2vdr Plugin hat da z.B. extra was drin damit Upstart erkennen kann wann der VDR wirklich fertig gestartet ist (d.h. der VDR wirklich bereit ist).

Upstart ist da ziemlich einfach gestrickt, Stichwort "expect stop". Wenn das im Upstart-Job drin steht, dann erwartet Upstart, dass der gestartete Prozess ein STOP-Signal schickt, wenn es komplett bereit ist. Upstart schickt dann sofort ein CONT und kann dann mit den Abhängigkeiten weitermachen. Das ist das, was dbus2vdr macht, wenn die Upstart-Unterstützung aktiviert ist. Das STOP-Signal wird ausgelöst, wenn der vdr das erste mal im Main-Loop ist. Wenn er da ist, sollte er wohl vollständig initialisiert sein...
Das Schöne ist, dass man für die Upstart-Unterstützung keinerlei komische Abhängigkeiten braucht.

Wenn es einen ähnlichen Mechanismus für systemd gibt, würde ich es gerne in dbus2vdr einbauen. Das werde ich auch tun, sobald ich mal ein systemd-System zum Testen habe und wenn ich weiß, wie man systemd sowas mitteilen kann. Wenn das jemand weiß, klärt mich bitte auf. Ein Link zu einer Dokumentation würde mir auch vollkommen reichen, lesen kann ich selbst...

Zitat von Mreimer

Die Lösung mit der Pfadprüfung ist interessant...

Ich würde mindestens noch dvr0 dazunehmen, das braucht der vdr auch.

Lars.

Moin!

Zitat von seahawk1986

Die schönste Lösung wäre das dynamite-Plugin

...und zusätzlich das Sundtek-Plugin. Das redet nämlich direkt mit dem Sundtek-Treiber und sagt dynamite, wenn neue Geräte kommen oder vorhandene abgezogen werden.

Lars.