Hunderte SQL-Fehler von der "/var/edomi-backups/_public/www/shared/php/base.php"

[Doenges]

ein Neustart ergab ein Netzwrrkproblem mit der VM, ich melde mich sobald ich was neues habe - Danke

[Doenges]

Guten Morgen, entschuldige die späte Rückmeldung.


Leider kommen nach wie vor diese hunderte Fehlermeldungen nach ein paar Minuten Laufzeit von Edomi.


Hier ist das Errorlog (beginnt mit dem Start der Maschine heute morgen) und das Telegram Log welches den Inhalt seit mehreren Tagen beinhaltet)

Archiv.zip


Und hier der Beweis, daß die Autoload.php da ist:

Bildschirmfoto 2018-08-14 um 08.45.05.png

[jonofe]

Der autoload.php Fehler ist ja offensichtlich nicht mehr vorhanden, d.h. die Installation ist scheinbar korrekt verlaufen.
Die mysql Fehler kommen nicht vom Telegram Contact, zumindest nicht direkt, da in diesem LBS gar keine mySQL Verbindungen explizit aufgebaut werden.
Hast du zufällig auch den Telegram-Receiver aktiv?

[Doenges]

Nein, war geplant, aber ich habe dieses LBS noch nicht mal installiert.

[jonofe]

Ehrlich gesagt, hab ich keine Idee mehr, woher die mysql Fehler kommen.
Kannst du dich denn auf der Kommandozeile mit dem mysql Server verbinden

[root@edomi-development ~]# [B][COLOR=#FF0000]mysql -u root -h 127.0.0.1[/COLOR][/B]
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 8516
Server version: 5.1.73 Source distribution

Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql>

Und vielleicht mal testen, ob dein Local Loopback interface noch existiert:

[root@edomi-development ~]#[COLOR=#FF0000][B] ifconfig[/B][/COLOR]
eth0      Link encap:Ethernet  HWaddr 00:50:56:00:00:11  
          inet addr:192.168.0.231  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::250:56ff:fe00:11/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4569504 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4843916 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:839797898 (800.8 MiB)  TX bytes:776233049 (740.2 MiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:85980039 errors:0 dropped:0 overruns:0 frame:0
          TX packets:85980039 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:13164595143 (12.2 GiB)  TX bytes:13164595143 (12.2 GiB)

[Doenges]

Klar, kann ich machen:


Klar, kann ich machen, hier der Output.

 
 [root@edomi_vm ~]# mysql -u root -h 127.0.0.1 Welcome to the MySQL monitor.  Commands end with ; or \g. Your MySQL connection id is 28617 Server version: 5.1.71 Source distribution  Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights reserved.  Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.  Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.  mysql>

 
 ifconfig eth0      Link encap:Ethernet  Hardware Adresse 08:00:27:3E:6F:D5             inet Adresse:192.168.178.100  Bcast:192.168.178.255  Maske:255.255.255.0           inet6 Adresse: 2001:4dd2:df47:0:a00:27ff:fe3e:6fd5/64 Gültigkeitsbereich:Global           inet6 Adresse: fe80::a00:27ff:fe3e:6fd5/64 Gültigkeitsbereich:Verbindung           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1           RX packets:18438 errors:0 dropped:0 overruns:0 frame:0           TX packets:11970 errors:0 dropped:0 overruns:0 carrier:0           Kollisionen:0 Sendewarteschlangenlänge:1000            RX bytes:1956586 (1.8 MiB)  TX bytes:4111118 (3.9 MiB)  lo        Link encap:Lokale Schleife             inet Adresse:127.0.0.1  Maske:255.0.0.0           inet6 Adresse: ::1/128 Gültigkeitsbereich:Maschine           UP LOOPBACK RUNNING  MTU:16436  Metric:1           RX packets:2351066 errors:0 dropped:0 overruns:0 frame:0           TX packets:2351066 errors:0 dropped:0 overruns:0 carrier:0           Kollisionen:0 Sendewarteschlangenlänge:0            RX bytes:345648655 (329.6 MiB)  TX bytes:345648655 (329.6 MiB)

[Doenges]

gaert - Hast Du vielleicht eine Idee ansonsten sehe ich mich gezwungen alles händisch neu (nach) zu bauen und hoffen, daß dann der Fehler weg ist.

[Doenges]

Nochwas herausgefunden, vielleicht hilft es ja. Die Uhrzeit des Servers wird "angehalten" während der zeit wenn Edomi durch diese Fehler nicht erreichbar ist.

Von diesem Moment an läuft die Uhr von Edomi hinterher.

Kann es sein, dass deswegen der Server nicht erreichbar ist? weil die Uhrzeit ein Teil im query ist???

Bildschirmfoto 2018-08-14 um 11.14.41.png

Die Fehler passierten zwischen 10:28:28 und 11:09:26.


Hier die Logs:


Edomi mysql Fehler.zip


Mit dem Befehl:
tpdate -u 0.europe.pool.ntp.org
kann ich die Uhrzeit wieder richten, danach aber wieder das gleiche Spiel.

[Doenges]

es wird nicht besser

Bildschirmfoto 2018-08-14 um 12.46.38.png

[Glotzkowski]

Nutzt Du VMware unter MacOS?
Findet evtl. zu den Fehlerzeiten ein Timemachine Backup des Mac mini statt und die VM bzw. der Host bekommt dadurch dicke Backen?

Hier hatte gaert dazu seine Meinung geschrieben.

[Doenges]

Ich gebe ihm grundsätzlich recht, aber mein Problem sehe ich auch auf der 2ten physikalischen Maschine, nicht nur in der VM. Setze gerade meine Fujitsu Kiste neu auf und werde alles nochmal schön loggen.

@VM: Es liegt, zumindest in meiner, Natur immer mal wieder zu versuchen zu optimieren. Mein MacMini ist ziemlich alt und langweilig sich halt trotzdem den ganzen Tag, bis auf TimeMachine und Empfänger für meinen Dokumentenscanner macht der -noch- nicht viel.

[gaert]

Solche "Consumer-VMs" synchronisieren gerne die VM-Uhr mit dem Host irgendwie (und irgendwann)... Könnte es vielleicht daran liegen?

[Doenges]

Guten Morgen,

ich konnte die VM Risiken minimieren aber immer noch kamen die Fehler.
Des Weiteren konnte ich auf einer separaten, realen, Maschine den Fehler auch produzieren - gleiches Modell was bei mir auch in Betrieb ist.

Da ich mit meinem Latein am Ende bin habe ich mich daran gemacht die Logiken von Hand nachzubauen auf einer kompletten neuen Edomi Installation mit 1.6

Ihr könnt Euch ja vorstellen wie ich zur Zeit das Feature von import/export von Logiken und UIs vermisse.

Eine Frage habe ich allerdings, kann ich die Fotos aus dem Kameraarchiv von der alten Maschine einfach so rüberkopieren oder sind die auch verloren? Die DB hat bestimmt was dagegen, weil Sie ja keinen Eintrag zu jedem Foto hat, oder?

[Doenges]

Ok, wieder ein Schritt weiter - es stellte sich heraus, daß ich bei einer Logik ganze 22 mal das Telegram LBS benutzt habe - Als ich diese Logik auf der neuen Maschine erstellt hatte bekam ich die gleichen Fehler.

Nun, habe ich dank dem Tip von gaert den Fehler behoben und es sind nur noch 2 Logiken, statt 22.

Kann es sein, daß die schiere Anzahl an LBS in einer Logik dieses Problem verursacht haben?

[gaert]

Ich kenne diesen LBS nicht im Detail - mag schon sein, dass dieser mit 22 Instanzen irgendwie nicht klarkommt. Aber generell kannst Du ruhig hunderte (tausende) von LBS einsetzen - hängt natürlich am Ende von der Leistung Deines Systems ab.