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.
Upstart: Wie kann man den VDR und die Plugins ereignisbasiert gestalten?
- HolgerR
- Geschlossen
-
-
hallo,
ich würde das mit einer while schleife lösen. ansonsten würde ich zur prozessüberwachung monit benutzen (siehe http://mmonit.com/monit/)
grüße
-
Zitat
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ß
HolgerPS: 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
-
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
-
[Ketzerei] Braucht's gar 'ne Schnittstelle im VDR, die den Plugins zur Verfügung gestellt wird? [/Ketzerei]
-
Zitat
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.ZitatOriginal 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
-
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
-
... 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? -
Zitat
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
-
Zitat
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
-
-
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 ABer gehen wir hier nicht etwas zu weit Das ist nur ein VDR
Ich kann nur sagen Upstart rocket!
-
Zitat
Ich glaube nicht, dass sich Klaus auf eine Abhängigkeit zu upstart einlässt.
ich hoffe dass OpenSuSE auch bald upstart benutzt -
Zitat
ABer gehen wir hier nicht etwas zu weit Das ist nur ein VDR
Also wenn Du Dir mal ein LinVDR (doch, es soll noch die ein oder andere aktive Box geben ) 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. -
Zitat
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
-
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.
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!