Edomi Totmacher

[wintermute]

Hi Christian,

wenn ich in einen (beliebigen) Logikbaustein irgendwo

blah("blubb");

reinschreibe, dann faellt Edomi irgendwie in ein Loch aus dem ich selber es nicht mehr rausbekomme (nur durch Neuinstallation).

Der Grund ist mir natuerlich klar, es ist ein nicht erkannter Syntax-Fehler im Baustein. Aber bevor (zB durch einen simplen Tippfehler) alles kaputt geht, waere es doch vllt anzuraten, die LBS irgendwie in ein eval zu kleiden. Denn sonst stirbt Deine Logikengine und der Server landet im Dauer-Reboot.

Und sag jetzt nicht wieder irgendwas ueber Performance

gruesse :: Michael

[gaert]

Sicher - ein LBS ist nichts anderes als eine PHP-Funktion. Und wenn dort eine Execption ausgelöst wird, wird der Prozess prinzipbedingt beendet. EDOMI merkt dies natürlich und macht einen Reboot.

Wenn man einen LBS entwickelt, sollte man genau wissen, was man tut - schließlich programmiert man quasi direkt im "Kernel" rum Wenn man auf Nummer sicher gehen will: try..catch... (allemal sinnvoller als eval()... also bitte...)

Du hättest EDOMI allerdings nicht gleich neu installieren müssen: Nach dem Reboot kannst Du den EDOMI-Start mit ENTER abbrechen (3s lang) - genau für solche Bootschleifen ist dieses "Feature" gedacht.

Und schließlich: EDOMI ist keine Entwicklungsumgebung... Der LBS-Code sollte also extern getestet werden, bevor er implementiert wird. Schon aus Gründen des Komforts...

[wintermute]

Wie schon geschrieben ist mir durchaus klar wieso das passiert

Ob nur try oder eval ist akademisch, mir gings eher ums Prinzip.

Und Edomi beim Starten abzuwuergen ist das eine, die Frage ist eher wie ich den defekten Logikbaustein aus der CFG bekomme. Denn i-wie schaffe ich es nur ein Projekt zu aktivieren (mal abgesehen vom Aendern) wenn Edomi laeuft - und genau das ist ein Zustand den ich ja nicht mehr hinbekomme. Aber da kannst Du sicher helfen.

Generell wollte ich nur auf einen (IMHO) sehr krassen Bug hinweisen der ohne weiteres durch einen Tippfehler auftreten kann - und wenn tatsaechlich mal jemand etwas komplexeres als ein 2fach Und-Gatter aufsetzen will (ja, sowas kommt vor ), dann ist das Testen in der Console nicht immer der Schritt nach vorn - zB Eingaenge belegen und schauen was passiert ist ohne vorhandene Eingaenge... naja, Du weisst schon

gruesse :: Michael

[gaert]

Stimmt - es gibt noch keine (offizielle) Funktion zum Entfernen des LBS... Ich habe natürlich auch diverse "Abstürze" bei der LBS-Entwicklung erleben dürfen, aber ich weiß ja, wie man da wieder raus kommt

Ich würde dieses Verhalten allerdings nicht als "krassen Bug" bezeichnen wollen. Wenn Du im EDOMI-Quelltext einen Fehler einbaust, wird die Sache ähnlich ausgehen Ist das dann ein Bug?! Soll EDOMI seinen eigenen Quelltext überwachen?

LBS entwickelt man ja i.d.R. nicht auf einem Produktivsystem, sondern in einer VM - d.h. ein "Absturz" tut nicht weh. Ich mache mir mal Gedanken dazu, wie man "geschmeidig" aus der Bootschleife rauskommt.

[wintermute]

LBS entwickelt man ja i.d.R. nicht auf einem Produktivsystem, sondern in einer VM - d.h. ein "Absturz" tut nicht weh. Ich mache mir mal Gedanken dazu, wie man "geschmeidig" aus der Bootschleife rauskommt.

Ich koennte mir eine Art safe-Mode vorstellen - wo dann zB externer Code gesichert ausgefuehrt wird. Also beim letzten Mal mit Fehler neu gestartet, diesmal lieber auf Nummer sicher gehen.

Die Reboot-Schleife ist (mir persoenlich) uebrigens recht Schnuppe - mich taete eher interessieren wie ich mein Edomi wieder ans laufen bekomme. Ich kann ja nix mehr machen - gut, Backup einspielen hab ich zugegebenermassen nicht probiert, ich hab naemlich keins
Daher war bei mir die Neuinstallation inkl. Verlust aller Daten der einzige Weg.

Und: auf den Edomi Quelltext hat der unbedarfte Nutzer ja keinen Zugriff. Mir gehts um versehentliche Fehlbedienungen, absichtlich kaputt machen kann man jedes System. Aber wenn eine Fehleingabe zum kompletten Datenverlust fuehrt, ja, dann ist das ein "krasser Bug" - mit der Meinung bin ich sicher nicht alleine in der IT-Welt

gruesse :: Michael

[ggt]

... Ich kann ja nix mehr machen - gut, Backup einspielen hab ich zugegebenermassen nicht probiert, ich hab naemlich keins
Daher war bei mir die Neuinstallation inkl. Verlust aller Daten der einzige Weg ...

Ein Backup wird per default täglich 00:00:00 erstellt. In deinem Fall hättest du an der Console den edomi Start abrechen und dir die Backup-Files aus /var/edomi-backups herunterladen können.

[gaert]

Also mal im Ernst: Es geht hier weder um eine "Fehleingabe", noch um Datenverlust. Da geht nix verloren. Und die "Fehleingabe" bezieht sich auf das Entwickeln(!) von Bausteinen - also eher eine Sache für Programmierer.

Einen Safe-Mode habe ich natürlich auch im Hinterkopf - ist nur nicht mal eben in 2 Minuten implementierbar. Leider kann man in PHP keinen Vorab-Check durchführen, also z.B. auf undefinierte Funktionen abklopfen. Dazu müsste der Code geparsed werden und jeder einzelne Funktionsaufruf (oder was auch immer...) durchleuchtet werden. Und ich habe nicht vor auf die Schnelle einen PHP-Interpreter zu bauen

Die eval()-Lösung ist keine wirkliche Lösung - viel zu langsam (in der aktuellen Implementierung zumindest): Die Logikengine müsste ja jeden LBS bei Bedarf aus dem Dateisystem lesen und eval() anwenden. Aktuell werden die LBS quasi inkludiert und stehen somit direkt als PHP-Funktion bereit.

EDIT: eval() löst auch das Problem nicht - Fatalerrors führen in PHP immer zum Abbruch und können nicht abgefangen werden.

Aber keine Sorge, Herr "IT-Experte ohne Backups" - ich werde mir schon etwas einfallen lassen...

[wintermute]

Ein Backup wird per default täglich 00:00:00 erstellt. In deinem Fall hättest du an der Console den edomi Start abrechen und dir die Backup-Files aus /var/edomi-backups herunterladen können.

Stimmt, wusste ich garnicht
In meinem Fall war das "Neuinstallieren" aber kaum aufwendiger, denn es gab in der Installation nur eine Logikseite und 2 LBS. Deswegen gabs auch kein anderweitiges Backup davon und nicht etwa weil ich doof bin

Uhm... also wenn die inkludiert werden, wieso kann man dann um die inkludierten Files nicht einfach eval() drumrumschreiben? Mal ganz doof gefragt... der Variablengueltigkeitsbereich bleibt doch gleich (AFAIK). Aber ja, ich weiss.. die Performance
Wenn Edomi weiss welcher Logikbaustein betroffen ist koennte man ihn ja automagisch deaktivieren, aber vermutlich ist das (mal wieder) nicht so einfach. Wie Du schon schreibst, irgendwas wird dir sicher einfallen.

Im uebrigen will ich hier nicht rummotzen, sondern auf moegliche Fehler hinweisen. Wenn ich mich haette beschweren wollen, dann haette das anders geklungen (und vermutlich haette ich auch ein Backup in der Hinterhand gehabt)

[gaert]

Ich hab's auch nicht als "motzen" aufgefasst - daher die zahlreichen Smilies

Es ist so: In PHP werden Fatalerrors IMMER zu einer Beendigung des Scripts führen - egal ob eval() oder include(). Eval() verhält sich letztlich (fast) so wie inklude(). Das bringt also rein garnix. Von der Performance ist's grundsätzlich wurscht, auch eine Implementierung von eval() anstelle von include() wäre jetzt keine große Sache. Nur bringt es wie gesagt nichts in diesem Kontext, sondern bringt eher andere Nachteile mit sich.

Ein "Pre-Check" der LBS ist also nicht möglich... Es liegt in der Natur der Sache, dass Fehler dieser Art (also z.B. undefined functioncalls) ja erst beim Ausführen des Codes eine Exception schmeißen - da ist also ein "Trockendurchlauf" sinnlos.

Das einzig mögliche: Man könnte die Fatalerrors catchen (und z.B. loggen) - aber das Script wird trotzdem beendet. Dies ist nunmal leider so in PHP.

Mein Vorschlag daher: Sobald die Logikengine aufgrund derartiger Fehler abschmiert, wird EDOMI wie gehabt beendet - jedoch erfolgt dann kein Reboot oder Neustart, sondern man landet auf dem Prompt (das Problem ist ja ohnehin nur für Entwickler von Bedeutung).

Dort kann man dann ganz einfach den oder die LBS löschen (oder einfach alle LBS löschen): Natürlich nicht die LBS in www/admin/lbs, sondern im Ordner des Liveprojekts: www/data/liveproject/lbs - also z.B. # rm -f www/data/liveproject/lbs/*.*

Dies hat zur Folge, dass die Logik natürlich nicht mehr funktionieren wird... Ist klar. Aber EDOMI kann dennoch gestartet werden (# sh usr/local/edomi/main/start.sh) und man kann nach der Korrektur des LBS wieder das Projekt aktivieren. Es wird nämlich in der Logikengine durchaus überprüft, ob der LBS überhaupt vorhanden ist - falls nicht, wird dies angefangen.

Leider ist es nicht ohne weiteres möglich herauszufinden, warum der Logic-Prozess abgeschmiert ist (also welcher LBS der Schuldige war, oder ob irgendein anderes Problem vorlag). Aber wie gesagt: LBS sind was für Entwickler, nicht für "Konsumenten". Daher braucht's m.E. keine tolle Save-Mode-GUI mit allem Schnickschnack

[Monti]

Oder könnte man nicht in den drei Sekunden, in denen man den Edomi-Start abbrechen kann, einfach S für den Save-Mode drücken? Also einfach sämtlichen Logiken im Live-Projekt deaktivieren.

[gaert]

Klar, aber was bringt das? Wenn man S dann NICHT drückt, landet man eh wieder in einer Schleife...

EDOMI ist grundsätzlich so konzipiert, dass es bei Problemen sauber beendet und dann definiert neustartet. Nur wenn ein LBS fehlerhaft programmiert ist, kann EDOMI auch nix mehr machen... Die aktuelle Lösung (Bootschleife) ist in DIESEM Kontext natürlich Käse, das ist richtig. Aber was ist z.B. wenn aus irgendwelchen anderen Gründen die Logik (oder ein anderer Programmteil) versagt? Dann ist diese Verhalten (Reboot und Neustart) eigentlich sehr sinnvoll: Man stelle sich vor EDOMI oder die Hardware stürzt ab, aber nur aufgrund eines akuten Problems - dann ist es doch äußerst sinnvoll, wenn alles von selbst wieder zum Laufen gebracht wird damit man nicht im Dunkeln steht oder die Alarmanlage ihren Dienst einstellt...

[gaert]

So, ich habe jetzt mal einen Errorhandler für Fatalerrors ergänzt. Das sieht dann z.B. so aus:

Datei: /usr/local/edomi/www/data/liveproject/lbs/LBS15000053.php | Fehlercode: 1 | Zeile: 5 | Call to undefined function hhh() FATALERROR

Darauf aufbauend werde ich nun einen "Save-Mode" bauen, d.h. immer wenn ein Fatalerror in einem LBS (und nur dort) auftaucht, wird EDOMI beendet und der LBS wird gelöscht (nur die Kopie im Liveprojekt natürlich). Anschließend kann EDOMI zumindest schonmal wieder durchstarten - alles Weitere überlege ich mir noch

[wintermute]

Mein Vorschlag daher: Sobald die Logikengine aufgrund derartiger Fehler abschmiert, wird EDOMI wie gehabt beendet - jedoch erfolgt dann kein Reboot oder Neustart, sondern man landet auf dem Prompt (das Problem ist ja ohnehin nur für Entwickler von Bedeutung).

Find ich gut

Dort kann man dann ganz einfach den oder die LBS löschen (oder einfach alle LBS löschen): Natürlich nicht die LBS in www/admin/lbs, sondern im Ordner des Liveprojekts: www/data/liveproject/lbs - also z.B. # rm -f www/data/liveproject/lbs/*.*

Genau DAS ist die Info die mir gefehlt hat. Dadurch ist alles nur noch sowild/2

Aber wie gesagt: LBS sind was für Entwickler, nicht für "Konsumenten". Daher braucht's m.E. keine tolle Save-Mode-GUI mit allem Schnickschnack

Seh ich auch so. Allerdings kann es auch unter anderen Umstaenden zu dem Problem kommen: zum Beispiel bei Bausteinen die eigene Libs mitbringen und versehentlich nicht installiert wurden oder bei Bausteinen die PHP-Erweiterungen benoetigen die nicht installiert wurden. Es gibt bestimmt auch noch geschaetzte 600 andere die man eh nicht alle abfangen kann - drum ist das im Endeffekt dann auch egal...
Ich hatte nur das Problem, dass mein Edomi "kaputt" war, ich daher im Projekt nix aendern konnte und mir gedacht habe, jetzt manuell irgendwo irgendwas zu loeschen wird das Problem eher verschlimmbessern statt zu beheben.
Wenn der Reboot nicht mehr ist und man weiss wie man das Dingen wieder auf die Beine bekommt ist das IMHO alles kein Problem mehr.

Eine andere Frage, auf die ich komme weil es da auch um eval und sowas in der Art geht. Ich brauche hier einen Hostcheck der nicht nur pingt, sondern auch TCP Ports scannt. Das Problem ist, dass PHP ein Warning wirft falls zB der Port nicht erreichbar ist (scheinbar egal welches Paket an Socket-Funktionen man benutzt). In der Console kann ich das Warning "abschalten" wenn ich statt

$foobar=fsockopen(..:) 

ein

$foobar=@fsockopen(..:) 

verwende. Schoen und gut, im LBS wird aber trotzdem das Warning geworfen und problematischerweise landet das im Edomi-Error-Log wo es dann gammelig wird, unschoen ausschaut und im Endeffekt zu Verwirrung fuehren koennte.
Mittlerweile hab ich verschiedenste Socket-Funktionen, eval, try&catch, error_reporting(0) und was-weiss-ich-noch-alles ausprobiert.
Faelt Dir vllt irgendein Weg drumrum ein?

gruesse :: Michael

[gaert]

Das Problem kann unter den von Dir genannten Umständen NICHT auftreten: Eigene Libs/etc. sind nur im EXEC-Teil erlaubt - und der läuft ja als eigener Prozess. Wenn der abschmiert, juckt's EDOMI nicht die Bohne

Zu Deiner Socket-Frage:
EDOMI verbiegt die Errorhandler, u.a. um Fehler loggen zu können und auf Fehler generell reagieren zu können (siehe Fatalerror... )
Das @... bringt daher nichts. Aber es gibt ein ganz einfache Lösung: Die Errorhandler wieder zurücksetzen (dann werden allerdings auch keine Fehler mehr geloggt):

restore_error_handler();
error_reporting(0);

Dies ist natürlich auch nur im EXEC-Teil erlaubt!

EDIT: und set_time_limit(0); nicht vergessen im EXEC-Teil (siehe Dämon-Vorlage)

EDIT2: PHP ist nunmal leider nicht so mächtig wie "normale" Sprachen (C++ oder Java). Gerade die Fehlerbehandlung ist relativ dürftig. Ich habe übrigens selbst an PHP mitgearbeitet - trage also eine Mitschuld

[gaert]

Planänderung: Statt auf den Prompt zu hüpfen werde ich es so lösen: Nach einem LBS-FatalError wird EDOMI pausiert (gelb) und auf der Statusseite erscheint eine Meldung wie "LBS19000001: FatalError". Details gibt's dann im FehlerLog.

Vorteil: Man kann EDOMI wie gewohnt bedienen, den LBS korrigieren und dann starten.