\nYAML<\/a> heisst YAML Ain’t Markup Language, und ist so eine Art Sprache, die man benutzen kann, um Daten zu serialisieren. Im Gegensatz zu XML, mit der YAML oft verglichen wird, ist das explizite Ziel von YAML auch noch von Menschen lesbar und editierbar zu sein. Dazu verwendet YAML eine Mischung von speziellen Zeichen und Indentierung. Weiterhin kann man YAML auch in einem Stream-Context verwenden. Wenn man also nur eine Kommunikationspipe hat, kann man darüber mit YAML getrennte Dokumente übermitteln. In dem Fall von Process-Watch werden nur die “einfachen” Features von YAML unterstützt. Eine Beispielskonfigurationsdatei sieht so aus:\n<\/p>\n \nDiese Konfigurationsdatei lässt sich ungefähr so lesen: Es gibt 3 Knoten in der Datei. Die Knoten heissen “Sleeper”, “Test” und “Top”, und sind Kommandos, die Process-Watch überwachen soll. Jeder Knoten ist ein Mapping, d.h. z.B. eine Hashtabelle. Der Key “command” ist jeweils das Kommando, das ausgeführt werden muss. Der Parameter “graceTime” ist dazu da, einem Prozess bevor er gekillt wird ein bisschen Zeit zu geben. Ein Prozess wird gekillt, wenn in der Steueroberfläche ein Stop-Kommando abgesetzt wird, oder Process-Watch allgemein gestoppt wird. Der Parameter “activateOnStartup” ist dazu da, um ein Prozess nicht gleich beim Starten von Process-Watch zu starten. Wie man sehen kann, sind die “command”-Parameter vollwertige Shellkommandos, mit Pipes, usw… Daher kann man z.B. Programme wie unseren FEC-Streamclient gleich mit mpg123 über Process-Watch starten:\n<\/p>\n \nHier sieht man auch gleich an dem “maxLogItems”-Parameter, dass Process-Watch nicht nur Programme ausführen kann, sondern auch ihre Ausgaben mitloggen kann, und über die Kontrollschnittstelle anzeigen kann.\n<\/p>\n \nProcess-Watch im Einsatz<\/strong>\n<\/p>\n \nGanz “user”-friendly ist Process-Watch noch nicht, und im Moment ist der Name der Konfigurationsdatei (“config.yaml”) noch fest verdrahtet. Wenn man jetzt Process-Watch mit der obigen Datei startet, bekommt man folgende Konfigurationsoberfläche auf dem Port 8080:\n<\/p>\n \n Mit “start” und “stop” kann man hier die Programme starten und stoppen, mit “log” kann man den Output des Programms einsehen. Unten kann man auch noch die Konfiguration neuladen (wenn man z.B. neue Programme eingefügt hat). Process-Watch geht dabei recht klever vor, indem es nicht nur die Konfiguration dumm neulädt, sondern erkennt, welche Programme dazu gekommen sind, und welche gekillt werden müssen, und bei welchen sich die Parameter geändert haben.<\/p>\n Intern ist Process-Watch recht klar aufgebaut. Es gibt ein Master-Objekt, dass die laufenden Prozesse kontrolliert, und auch Anfragen von dem Webserver abarbeitet. Für die einzeln gestartete Prozess sind “WatchProcess”-Objekte zuständig. Das Hauptprogramm (die “main”-Routine, sozusagen) instanziiert ein “Master”-Objekt, einen HTTP Server, und biegt das “INT” Signal um, um Process-Watch sauber zu stoppen. Nachdem der Webserver instanziiert wurde, wird für die Url “\/” ein Handler angegeben, der die Anfrage an das Master-Objekt weiterleitet, indem es bei ihm die Methode “statusRequest” aufruft. Anschliessend wird der Webserver-thread gestartet, und alle 0.5 Sekunden wird dann der Master gepollt. Bei diesem Schritt überprüft er dass jeder Prozess richtig läuft, usw… Hier dieses Hauptprogramm:<\/p>\n Wie man sieht, wird hier die “eigentliche” Arbeit in der Methode “iteration” von dem Masterobjekt gemacht. Diese Routine sieht wie folgt aus:<\/p>\n Process-Watch benutzt 2 Threads (der Master-thread, und der Webserver-thread), und deswegen wird zur Synchronisation hier in “iteration” das Mastermutex reserviert. Innerhalb des Mutex geht dann der Masterprozesse alle gestarteten Prozesse durch (die in dem Array “@processes” gespeichert sind), und checkt, ob bei einem Prozess was von Stderr gelesen werden kann. Ist dies der Fall, dann stehen Daten für das Log bereit, und die Methode “onStderrReadable” wird bei dem “WatchProcess” Objekt aufgerufen. Nachdem die Logfiles aller gestarteten Prozesse aufgefrischt wurden, wird in der Method “collectDeadChilds” nachgeguckt, welche Subprozesse gestorben sind, und sammelt ihre Leichen auf. Schliesslich wird verifiziert, ob die Konfiguration neugeladen werden muss, was durch die “checkProcessConfig” Methode erledigt wird. Bei dem ersten Ausführen von “iteration” ist noch gar keine Konfiguration geladen worden, so dass diese Methode auf jedem Fall aufgerufen wird.<\/p>\n “checkProcessConfig” tut nichts anderes, als die YAML Konfigurationsdatei zu laden, und nachher “activateNewConfig” aufzurufen, die sich darum kümmert, die neuen Prozesse zu erkennen, die nicht-mehr existierenden zu identifizieren, und die modifizierten Parameter der gleich-bleibenden Prozesse zu übernehmen. Der YAML-Reader benutzt die YAML-Library für Ruby, und ist verheerend einfach \ud83d\ude42<\/p>\n Die neuen und alten Prozesse werden über ihren Namen identifiziert, also die Keys vom ersten Mapping in der YAML-Datei. Für jeden neuen Prozess wird ein neues “WatchProcess” Objekt instanziiert, was sich dann auch darum kümmert, zu Forken und den neuen Prozess auszuführen (und auch Stderr umzuleiten, damit die Nachrichten, die darüber kommen mitloggen zu können). Das ganze Unix-Handling ist ziemlich ekelhaft, und ich werde hier nicht näher drauf eingehen. Vermerken, dass Unix wirklich stinkt, muss ich allerdings schon.<\/p>\n","protected":false},"excerpt":{"rendered":" Dividuum war diese Woche ganz schön fleissig, und ich werde hier mal kurz über die Software bloggen die er geschrieben hat. Wir wollten demnächst die Welt mit unser Streaming-Software übernehmen. Doch dazu braucht man auch Software, die den Zustand der … Continue reading Sleeper:\n command: sleep 5\n\nTest:\n command: sleep 10\n graceTime: 2\n \nTop:\n command: top 1>&2\n graceTime: 3\n activateOnStartup: false\n<\/pre>\n
poc:\n command: ~\/progs\/poc\/pob-fec | mpg123 -\n maxLogItems: 30\n graceTime: 5\n<\/pre>\n
![\"Pw1-1\"](\"http:\/\/blogs.bl0rg.net\/netzstaub\/images\/pw1-1.png\")
\n<\/p>\nProcess-Watch Internals<\/h3>\n
done = false\n\ntrap(\"INT\") do \n done = true\nend\n\nmaster = Master.new(\"config.yaml\")\nhttp = WEBrick::HTTPServer.new(:Port => 8080)\n\nhttp.mount_proc(\"\/\") do |req, res|\n master.statusRequest(req, res)\nend\n\nhttpThread = Thread.new do \n http.start\nend\n\nuntil done do\n master.iteration\n sleep 0.5\nend\n\nhttp.shutdown \nhttpThread.join\nmaster.activateNewConfig({})\n<\/pre>\n def iteration\n @masterMutex.synchronize do \n fdlist = {}\n @processes.values.each do |process|\n fdlist[process.stderr] = process if process.stderr\n end\n readable, _, _ = *IO.select(fdlist.keys, nil, nil, 0)\n if readable\n readable.each do |fd| \n fdlist[fd].onStderrReadable\n end\n end\n \n collectDeadChilds\n checkProcessConfig\n end\n end\n<\/pre>\ndef readYaml(file)\n begin \n cfgfile = File.open(file)\n config = YAML::load(cfgfile.read)\n rescue SystemCallError => e\n puts \"error while reading configuration file #{file}: #{e}\"\n rescue ArgumentError => e\n puts \"error while parsing configuration file #{file}: #{e}\"\n ensure\n cfgfile.close\n end\n config\nend\n\ndef checkProcessConfig(reload = @mustReload)\n return unless reload\n @mustReload = false\n\n config = readYaml(@config)\n unless config\n log \"could not read configuration\"\n return false\n end\n activateNewConfig(config)\nend\n<\/pre>\n