Der Tipp bei Neustart mit dem aktiven Netzwerk verbinden, hat geholfen, vielen Dank. Steht sogar unter Schritt 9 im Installationsmanual🙄
-
-
Hat keiner eine Idee wie ich den Fehler los werde?Zitat von beauty Beitrag anzeigen
Dachte ein buggy LBS wäre das Problem, aber nix wars... die Fehlermeldung taucht immer noch alle paar Tage im Log auf.Kommentar
-
Es muss aber sowas sein, das war doch schon vor ein paar Jahren hier Thema.Kommentar
-
Ja hab einige Threads gefunden mit diesem Problem, aber da wurde keine wirkliche Lösung beschrieben.
Hab das curl update gemacht und den buggy LBS wie im passenden Thread geschrieben nach besten wissen gefixt.
Aber der Fehler war heute wieder da....
Das einzigste was mir noch einfällt ist jede Logik einzeln zu deaktivieren und paar Tage warten und so systematisch den Fehler eingrenzen sofern es an einem LBS liegt
Kommentar
-
Ich würde das deaktivieren, was du kurz vor dem ersten Auftreten geändert hast, d.h. insbesondere die Seiten, wo du neue User-LBS hinzugefügt hast.
Du kannst ja mit top oder ps prüfen, ob die Speichernutzung eines php Prozesses konstant ansteigt. Dazu musst du nicht 3 Tage bis zum Fehler warten, das sollte man dann schon früher erkennen.
Kommentar
-
Danke für den Tip... es ist leider nicht mehr nachvollziehbar was geändert wurde und wann es war...hab den Fehler am Anfang auch brav ignoriert weil noch andere Dinge im argen lagen und einfach die Zeit fehlte. Nun sind alle anderen Fehler bereinigt nur dieser steht noch an.
Mit top hab ich schon geschaut, konnte aber nicht wirklich erkennen das ein php prozess ansteigt. War nur eine kurze Zeitspanne, werde das aber nochmals über eine längere zeit nachschauen.Kommentar
-
Nun habe ich mich endlich drangesetzt mein Hauptprojekt auf die Centos 7 anzuheben.
Wie erwartet musste ich einige LBS ersetzten, aber nun läuft alles soweit stabil.
Allerdings habe ich jede Menge Fehler im Logfile, die ich nicht finde
Im wesentlichen ist das immer die Meldung bei verschiedenen LBSz.B.A non well formed numeric value encountered
2022-02-06 11:13:15 361130 ? 2467 Datei: /usr/local/edomi/www/data/liveproject/lbs/LBS19000570.php | Fehlercode: 8 | Zeile: 19 | A non well formed numeric value encountered ERROR 2022-02-06 11:13:57 607281 ? 2467 Datei: /usr/local/edomi/www/data/liveproject/lbs/LBS19000570.php | Fehlercode: 8 | Zeile: 22 | A non well formed numeric value encountered ERROR 2022-02-06 11:13:57 609869 ? 2467 Datei: /usr/local/edomi/www/data/liveproject/lbs/LBS19000570.php | Fehlercode: 8 | Zeile: 19 | A non well formed numeric value encountered
Den Baustein habe ich aktualisiert. aber der Fehler bleibt.
Habt ihr eine Idee?
Gruß HartwigKommentar
-
Ich gebe mir mal selbst die Antwort.
Nachdem ich mir den verwendeten Baustein genauer angeschaut habe.
Es scheint dass die PHP Version sich hier anders als bei der Centos 6.5 verhält.
Der verwendete Baustein, wertet die Eingänge E1:E5 aus. Dabei wird E1 immer als numerischer Wert angenommen und zugeordnet.
Ist E1 aber leer, weil nach einen Neustart noch kein Wert anliegt führt dies unter Centos 7.6 zu einer Fehlermeldung.
Nachdem ich den Baustein nun umgebaut habe, sind die Fehler weg.Gruß HartwigKommentar
-
Hallo, ich habe bei mir das selbe Problem, was hast du den genau im LBS geändert? Gruß ThorstenKommentar
-
Ich am Ausmerzen der Fehlerlogs nach der Umstellung auf Centos 7
Bei einem Fehler komme ich nicht weiterer .
Ca 300x pro Tag schlägt diese Meldung auf.
Tipp?2022-02-20 09:31:08 815361 ? 58566 Datei: /usr/local/edomi/www/shared/php/base.php | Fehlercode: 2 | Zeile: 20 | utf8_decode() expects parameter 1 to be string, array given ERROR 2022-02-20 09:31:08 816107 ? 58566 Datei: /usr/local/edomi/www/shared/php/base.php | Fehlercode: 2 | Zeile: 20 | utf8_decode() expects parameter 1 to be string, array given ERROR
Gruß HartwigKommentar
-
Das liegt vermutlich an einem LBS, der versucht statt eines Strings ein Array auf einen Ausgang zu schreiben.
Eigentlich hätte der Fehler dann aber auch schon vorher auftreten sollen, denn utf8_decode() konnte meines Wissens noch nie ein array verarbeiten.
Ich sehe gerade, dass er auch vorher schon aufgetreten ist
Wird vermutlich schwierig sein ihn zu finden ...Kommentar
-
Ich würde es mit grep utf8_decode /usr/local/edomi/www/admin/lbs/* probieren. So viele Treffer sollten das nicht sein.Kommentar
-
Das wird nicht funktionieren, da das utf8_decode() ja in base.php aufgerufen wird und zwar dann, wenn ein LBS ein logic_setOutput() verwendet.Zitat von maque Beitrag anzeigen
incl_logic.php:
function logic_setOutput($elementid,$ausgang,$value)
{
logicMonitor_lbsCall_setOutput($elementid,$ausgang ,$value);
sql_call("UPDATE edomiLive.RAMlogicLink SET refresh=1,value='".sql_encodeValue($value)."' WHERE (linktyp=1 AND linkid=".$elementid." AND ausgang='".sql_encodeValue($ausgang)."')");
}
base.php:
function sql_encodeValue($n,$allowNull=false,$allowSeparators=false) { $n=utf8_decode($n); ...
D.h. der $value vom logic_setOutput() schlägt im sql_encode() als $n auf und wird dort vor dem Schreiben in die DB utf8_encoded. Und das geht mit einem Array nicht.
Kommentar
-
Man könnte zur Fehlersuche in logic_setOutput() als erste Zeile folgendes einfügen:
PHP-Code:if (is_array($value)) file_put_contents('/tmp/lbs.id','LBS: '.$elementid.' - Ausgang: '.$ausgang);
Wenn der Fehler dann auftritt sollte eigentlich in der Datei /tmp/lbs.id die ID sowie der Ausgang des verursachenden LBS stehen.
Kommentar
-
Danke für die Hilfe.
jonofe Ich habe mal die von Dir vorgeschlagen Zeile bei incl_logic.php in in die function logic_setOutput eingefügt.
Der Fehler ist auch bereits wieder x.mal aufgetreten. In /tmp/ habe ich aber keine neuen Einträge. Somit dürfte das nicht an einem Array hängen.
Interessent, dass ich den Fehler bei 1.51 schon mal hatte. Ich habe da keine Ahnung wie ich den Fehler damals fixen konnte. Jedenfalls kommt der Fehler jetzt erst wieder mit Centos 7.
Gruß HartwigKommentar
Kommentar