Upstart: Wie kann man den VDR und die Plugins ereignisbasiert gestalten?

  • Na, das sind ja spannende Sachen, die ihr hier macht. Ich habe zwar den Faden noch nicht aufgenommen, wie sich das ganze in Richtung der eigentlichen Problemstellung entwickelt, aber ihr macht das schon. :)

  • Quote

    Original von noname_gentoo
    ich würde das mit einer while schleife lösen. ansonsten würde ich zur prozessüberwachung monit benutzen (siehe http://mmonit.com/monit/)


    Hi,


    falls das mir gegolten hat: Danke, aber mein ursprüngliches Problem habe ich für mich mit dem Ändern der xineliboutput-Sourcen ja bereits gelöst. Zwar eher schmutzig, aber für mich sehr praktikabel. Ich verfolge jetzt hier nur noch gespannt die weitere Entwicklung der grundsätzlichen Idee die für mich heißt, den VDR und die Plugins mehr *ereignisbasiert* zu steuern. Wie gesagt: Sehr spannend. Auch wenn es hier manchmal ein wenig nach "einen Schritt vor und zwei zurück" aussieht.


    Gruß
    Holger

  • ... ich will das noch mal konkretisieren:


    Ob ein xineliboutput-, streamdev-client- oder fritzbox-plugin *startet* ist mir doch piepenhagen. Das tun die oder nicht, und wenn nicht gibt's ein Problem. Da muss ich eh' an das Log.


    Was *mich* interessiert sind die Statusmeldungen, die diese Plugins bisher einfach nur im Log abladen, ohne dass was passiert. *Mich* interessiert, wann das xineliboutput-plugin fertig ist zur Bedienung von Anfragen, wenn der streamdev-client kein Bild bingt wegen eines "buffer overflows" und wenn das fritzbox-plugin ein Problem hat, die Anruferliste einzulesen. All das passiert lange nachdem die Plugins signalisieren, sie seien "fertig". An diesen Stellen sind Logeinträge (die ja auch stattfinden) zwar interessant, aber eine automatische Reaktion darauf ist doch erst das, was wirklich spannend ist. Die Möglichkeit ist systemseitig mit "Upstart" jetzt vorhanden. Das sollten wir nutzen.


    Und das ist genau der Punkt wo mir bisher noch nicht klar ist, wo da jetzt der Ansatz ist diese Ereignisse aus ihrem "Syslog-Gefängnis" zu befreien und per Event nutzbar zu machen.


    Gruß
    Holger


    PS: Bitte nicht als Mißachtung der Bemühungen verstehen; so ist es nicht gemeint!
    PPS: War mal so frei den Threadtitel zu ändern, um den Focus des Threads hervor zu heben.

  • HolgerR
    Du hast absolut recht, was die meisten hier einfach nicht verstehen (wollen?), ist dass das Problem nicht von außen, oder an zentralen Stellen des VDR zu lösen ist. Die interessanten Ereignisse treten einfach nicht beim Start oder Ende eines Threads auf. Trotzdem bietet es sich an den Ansatz von Ebsi zu kombinieren mit der Idee, statt eines system calls mit initctl, ein Signal an ein Plugin zu schicken, dass dann von diesem Plugin an Upstart übermittelt wird.


    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

  • Hallo Gerald,


    danke! In diesem Thread geistern glaube ich schon ein paar Leute rum, die den Sinn des Threads erkannt haben. Bei einigen hat es aber einfach noch nicht *KLICK* gemacht, dass es nicht mehr darum geht, auf Probleme und Ereignisse mit "Schleifen" zu reagieren, sondern sie direkt anzugehen.


    Ich finde die Idee mit dem Plugin ebenfalls sehr charmant, obwohl ich ehrlich gesagt der Meinung bin, dass Distributionen ohne "Upstart" oder Pendants mittelfristig (in "IT-Zeit"; also schon sehr bald) komplett bedeutungslos werden. Auf ein "Archlinux" Rücksicht zu nehmen erscheint mir daher schon fast ein wenig konservativ. Mir aber egal, wenn's denn der Sache dient.


    Bleibt für mich die Frage:
    Wie empfängt das Plugin Events, die bisher nur im Log stattfinden? Die schmutzige "Lösung" ist ja ganz leicht: Das Prinzip ist so einfach, dass ich sogar *mir* zutraue, jedes von mir verwendete Plugin um ein "emit" zu ergänzen, wo es für mich interessant ist. Ich wollte nur nicht der Nächste sein, der hier sein eigenes PPA hat... ;)


    Gruß
    Holger

  • Das große Plus was ich da sehe ist halt, das nur dieses Plugin dann eine Abhängigkeit hat zu dbus oder von mir aus auch dem initctl binary. Und wenn man die Idee weiterspinnt kann man halt per plugin service calls an neuralgischen Punkten Nachrichten verschicken. Ist dieses Plugin da - kann man das wie auch immer zu upstart übermitteln, wenn es nicht da ist passiert nichts. Sprich es können Patches zu Plugins gegeben werden die dann von den Entwicklern aufgenommen werden können, da sie keine Seiteneffekte haben. Das setzt natürlich voraus das man weiss wo die neuralgischen Punkte sind. Das dürfte aber in vielen Situationen gegeben sein.


    Um aus Ereignissen aus dem Log events zu generieren müssten eigentlich Logparser existieren die man entsprechend konfiguriern kann. Da bei Logfiles ein paar Klippen zu umschiffen sind (zB logrotate) fällt mir spontan nix ein.


    EDIT: Naja jetzt allen upstart vorzuschreiben ist ein wenig vermessen. Ausserdem muss es sich erst beweisen. Das charmante am init system ist das es einfach zu kontrollieren ist und einfach zu durchschauen. Ausserdem läuft Linx auf mehr als HTPC oder Desktops. Auf Servern sollte es nicht allzu event basiert zugehen ;) Ausserdem: Linux lebt von Vielfalt. Und wenn jemand Archlinux verwenden will, oder LFS oder oder ist das auch ok. Um die Sachen abzudecken sollte man schon aufeinander Rücksicht nehmen. Ausserdem kommt man ohne Rücksicht auch nicht weit.


    Letztenendes ists ein neues Spielzeug und ziemlich interessant. Klar gibts Leute die sagen hatten wir noch nie/wollen wir nicht, aber das tut der Sache ja keinen Abbruch ;)

  • Quote

    Original von HolgerR
    Ich finde die Idee mit dem Plugin ebenfalls sehr charmant, obwohl ich ehrlich gesagt der Meinung bin, dass Distributionen ohne "Upstart" oder Pendants mittelfristig (in "IT-Zeit"; also schon sehr bald) komplett bedeutungslos werden. Auf ein "Archlinux" Rücksicht zu nehmen erscheint mir daher schon fast ein wenig konservativ. Mir aber egal, wenn's denn der Sache dient.


    Ich bin nicht ganz sicher ob du mich verstanden hast. Das neue Plugin soll im Auftrag der anderen Plugins mit upstart kommunizieren. Ich will damit der Problematik mit den Rechten aus dem Weg gehen.

    Quote

    Original von HolgerR


    Bleibt für mich die Frage:
    Wie empfängt das Plugin Events, die bisher nur im Log stattfinden? Die schmutzige "Lösung" ist ja ganz leicht: Das Prinzip ist so einfach, dass ich sogar *mir* zutraue, jedes von mir verwendete Plugin um ein "emit" zu ergänzen, wo es für mich interessant ist.


    Es wird einfach darauf hinauslaufen müssen, dass die Programme gepatcht werden. Nur, dass die Plugins über eine Standard-Methode dem neuen Plugin den Auftrag geben, das "emit" für sie zu machen.
    Sollte das neue Plugin nicht existieren und die gepatchten Plugins machen ein emit, dann passiert einfach gar nichts, die Plugins merken es nicht ein mal.


    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

  • Mir ist gerade noch etwas eingefallen. Wie wäre es, wenn wir einen SyslogHook in den VDR patchen? Dann könnte sich ein Plugin in diesen Hook einhängen und bekäme jede Syslog-Meldung zu sehen. Je nach Inhalt könnte sie dann "emitten".


    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

  • ... ich bin bei dir und hab' auch deinen Ansatz mit dem "Vermittler-Plugin" verstanden. Das bringt mich aber auch und wieder zu dem (gemeinsamen) Ansatz:


    Wäre ein Patch nicht sinnvoller als ein Plugin?


    PS: Der "Ketzerei"-Ansatz halt ;)

  • Oder anders ausgedrückt:
    Braucht man für das "Emitten" wirklich noch ein Plugin, wenn der VDR eine Schnittstelle für die bestehenden Plugins zur Verfügung stellt? Das kann er dann doch auch grad' selbst übernehmen. Oder bin ich da auf dem Holzweg?

  • Quote

    Original von HolgerR
    Oder anders ausgedrückt:
    Braucht man für das "Emitten" wirklich noch ein Plugin, wenn der VDR eine Schnittstelle für die bestehenden Plugins zur Verfügung stellt? Das kann er dann doch auch grad' selbst übernehmen. Oder bin ich da auf dem Holzweg?


    Du bist überhaupt nicht auf dem Holzweg, nur wäre ein Hook im VDR den ein Plugin benutzt vermutlich deutlich leichter irgendwann mal in den VDR zu bekommen. Ich glaube nicht, dass sich Klaus auf eine Abhängigkeit zu upstart einlässt.


    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

  • Quote

    Was *mich* interessiert sind die Statusmeldungen, die diese Plugins bisher einfach nur im Log abladen, ohne dass was passiert. *Mich* interessiert, wann das xineliboutput-plugin fertig ist zur Bedienung von Anfragen, wenn der streamdev-client kein Bild bingt wegen eines "buffer overflows" und wenn das fritzbox-plugin ein Problem hat, die Anruferliste einzulesen. All das passiert lange nachdem die Plugins signalisieren, sie seien "fertig". An diesen Stellen sind Logeinträge (die ja auch stattfinden) zwar interessant, aber eine automatische Reaktion darauf ist doch erst das, was wirklich spannend ist. Die Möglichkeit ist systemseitig mit "Upstart" jetzt vorhanden. Das sollten wir nutzen


    [Ketzerei] Braucht's gar 'ne Schnittstelle im VDR, die den Plugins zur Verfügung gestellt wird? [/Ketzerei]


    Ich denke, hier wäre es sinnvoll, die Kette der Beteiligten, die ein Ereignis passiert zu visualisieren.


    So wie oben skizziert, entsteht das Ereignis im Plugin.
    Das Ereignis selbst könnte aber innerhalb des VDR genauso von Bedeutung sein, wie außerhalb - deshalb ist der "Ketzerei"-Gedanke nicht falsch.
    In Java- und GUI-Anwendungen ist es lange schon selbstverständlich, mit Ereignissen zu "programmieren". Dort wird ganz klar getrennt zwischen dem Auslösen eines Ereignisses und dem Verarbeiten.


    Ich persönlich sehe das Weiterreichen eines Ereignisses an die Außenwelt (also nicht VDR) schon als Reaktion, bzw. als Verarbeitung des Ereignisses, deshalb schrieb ich in meinen ersten Beiträgen von Skripten, die es an DBUS weiterreichen oder - im Falle von Archlinux - eben was anderes machen.


    Das TODO wäre einmal, einen Callback-Mechanismus innerhalb des VDR bereit zu stellen, der von den Plugins bei Ereignissen verwendet wird. Ähnlich dem loggen. Kein Plugin benutzt den Systemcall direkt um eine Logausgabe zu machen. Dafür ist eine VDR-Funktion (oder Makro?) bereitgestellt, die allegemein verwendet wird - so kann eine Anpassung zentral an einer Stelle erfolgen.


    Wenn man dies bei den Ereignissen genauso handhaben würde, könnte man intern und extern auf die Ereignisse reagieren, ohne dass das Plugin wissen muss, wer Interesse an dem Ereignis angemeldet hat.
    In Java-Anwendungen ist es z.B. so, dass die Ereignisse immer auftreten, aber erst dann, wenn sich ein Interessent bei einem Ereignis anmeldet, erfolgt auch eine ereignisbaiserte Verarbeitung.
    In C/C++ kann man über Callbacks das gleiche erreichen.


    Aus Sicht des VDR wäre die Skriptschnittstelle zur Außenwelt das probate Mittel. Dies wird schon beim Ausschalten und anderen Stellen vom VDR verwendet. Warum also nicht auch hier?
    Nicht zuletzt erreicht man dadurch auch eine Unabhängigkeit von z.B. den DBUS-Bibliotheken ...


    Ich denke, Ereignisse, bei denen die Verarbeitung zeitkritisch ist, sollten sowieso innerhalb des VDR behandelt werden (egal ob zentral oder in einem Plugin). Bei den Ereignissen, die außerhalb verarbeitet werden, dürfte der Overhead des Scriptstartens zu verschmerzen sein ;)


    Gruß Geronimo

    Ich bin verantwortlich für das, was ich schreibe, nicht für das, was Du verstehst!

  • Quote

    Original von gda


    Na dafür bietet sich doch eher das Kommando an, welches ich HolgerR genannt habe:

    Code
    1. initctl emit xineliboutput-is-ready


    Gerald


    Diese Kommando soll aber erstmal automatisch gestartet werden, das geht auch schon.

    mfg traxanos
    ____________________
    Ist das neu?, Nein Linux!


    VDR1: Zotac NM10-ITX Wifi - 2GB Ram - S2-6400 HD mit IR - yavdr 0.4 (development) - LianLi PC-Q11


    Tags: VDR-HD - AT5IONT-I - 4GB Ram - 512MB ION - TT 3600 DVB-S2 - TT6400-FF - Sundtek DVB-S2 Sundtek DVB-C - Tevii S480 (dank an L4M für kostenlose Bereitstellung) - yaVDR 0.5 (development) - SKY - HD+ - Atric - X10 FB - Zotac ID41 PLUS - SilverStone LC19B-R - Yamaha RX-V671 - Samsung 8Series 55"

  • Was mich wunder warum alles so kompliziert, warum kann das VDR Startscript nicht nach dem starten, einfach mit netcat (wie auf seite 1 als beispiel) überprüfen ob der port offen ist. läuft hier 1a. hab sogar im initscript noch ein event wenn der vdr gestoppt wird, so dass das Frontend ebenfalls beendet wird.


    wenn man das ganze 100% sauber haben möchte, müsste jedes plugin selbst nach dem start ein event auslösen. z.B. vdr-plugin-xinelibout-started. für streamdev wäre das auch praktisch, wenn man mehrere vdrs auf einem rechner laufen mittels streamdev-server/client - als ein beispiel.


    Da finde ich die Idee von geronimo gut, das der VDR einfach Schnittstellen bereit stellt. So müsste eingentlich das Plugin dem VDR Sagen, pass auf, ich bin am starten, und jetzt bin ich fertig. und die Events müssen, fangbar sein, um eigene Evens/Programme aus zu lösen/zu starten. So könnte auch Plugin abhängigkeiten aufgelöst werden, starte das Plugin erst wenn das andere geladen ist. Also eingltich eine Upstart für VDR :D ABer gehen wir hier nicht etwas zu weit :D Das ist nur ein VDR :lol2



    Ich kann nur sagen Upstart rocket!

    mfg traxanos
    ____________________
    Ist das neu?, Nein Linux!


    VDR1: Zotac NM10-ITX Wifi - 2GB Ram - S2-6400 HD mit IR - yavdr 0.4 (development) - LianLi PC-Q11


    Tags: VDR-HD - AT5IONT-I - 4GB Ram - 512MB ION - TT 3600 DVB-S2 - TT6400-FF - Sundtek DVB-S2 Sundtek DVB-C - Tevii S480 (dank an L4M für kostenlose Bereitstellung) - yaVDR 0.5 (development) - SKY - HD+ - Atric - X10 FB - Zotac ID41 PLUS - SilverStone LC19B-R - Yamaha RX-V671 - Samsung 8Series 55"

  • Quote

    ABer gehen wir hier nicht etwas zu weit :D Das ist nur ein VDR :D


    Also wenn Du Dir mal ein LinVDR (doch, es soll noch die ein oder andere aktive Box geben :D ) anschaust, dort ist der VDR das "komplette Betriebssystem", bzw. der Desktop. Alles wird über den VDR gesteuert - also ich sehe das nicht als wenig an!


    ... und ich bin mir ziemlich sicher, auch wenn die Sonne demnächst nur noch in HD aufgeht, dass es immer Anwender geben wird, die einen möglichst schlanken VDR haben möchten ;)
    ... da wäre es doch nicht schlecht, wenn die Ereignisse für alle verwendbar würden und blieben.

    Ich bin verantwortlich für das, was ich schreibe, nicht für das, was Du verstehst!

  • Quote

    Original von geronimo
    ... da wäre es doch nicht schlecht, wenn die Ereignisse für alle verwendbar würden und blieben.


    Das mag ja alles sein, aber der Themenstarter HolgerR hat jetzt schon mehrfach gesagt, dass er anders darüber denkt. So wie ich auch. Ich würde mich deshalb freuen wenn die Diskussion in diesem Thread auf HolgerRs Thema beschränkt werden könnte. Das ist jetzt wirklich nicht böse gemeint.


    Übrigens beurteile ich LinVDR völlig anders. LinVDR war seinerzeit so gut, weil es relativ spezialisiert und eben nicht sehr universell war. Viele der sehr interessanten Ideen sind nicht ohne Aufwand in aktuelle Distributionen zu übernehmen.


    Und vor die Wahl gestellt, eine Lösung zu entwickeln die unter bestimmten Voraussetzungen perfekt funktioniert, oder eine generelle Lösung zu erstellen, die es nur beinahe schafft, wähle ich die erste.


    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

  • Moin!


    Wie wäre es, wenn ihr erst mal eine Liste aller gewünschten Events erstellt, damit man mal einen Überblick hat? Wenn man dann erst mal die Stellen im VDR bzw. den entsprechenden Plugins identifiziert hat, wird aus den Puzzleteilen vielleicht ein Bild.


    Es fing damit an, zu wissen, wann das xineliboutput-Plugin bereit für Anfragen von außen ist. Ähnliches könnte wohl auch für das streamserver-Plugin gelten.


    Was noch?


    mini.