FHEM Forum

Moin,

hab heute ein Update gemacht und auch configDB wurde upgedatet - seitdem bekomme ich beim speichern ein error

2022.03.04 10:52:00.790 1: PERL WARNING: DBD::mysql::st execute failed: MySQL server has gone away at configDB.pm line 425.
DBD::mysql::st execute failed: MySQL server has gone away at configDB.pm line 425.
2022.03.04 10:52:00.791 1: PERL WARNING: Issuing rollback() due to DESTROY without explicit disconnect() of DBD::mysql::db handle database=fhem_configDB;host=nas;port=3307 at configDB.pm line 425.

moin,

mach mal bitte


attr global stacktrace 1
attr global verbose 4


und versuche dann nochmal zu speichern. Das sollte im Logfile mehr Informationen liefern, mit denen man auf die Suche gehen kann.
An der bemängelten Stelle (line 425) selbst wurde nichts geändert.

Zitat von: betateilchen am 04 März 2022, 11:19:06
moin,

mach mal bitte

Code Auswählen Erweitern


attr global stacktrace 1
attr global verbose 4


und versuche dann nochmal zu speichern. Das sollte im Logfile mehr Informationen liefern, mit denen man auf die Suche gehen kann.
An der bemängelten Stelle (line 425) selbst wurde nichts geändert.

Moin,

hier mal mit Verbose 4 (nur der Teil mit dem Fehler)

022.03.04 11:21:42.275 4: configDB writing file: dd0c65db2a4b84adbf1826fd708efba1.fhem.save
2022.03.04 11:21:42.332 1: PERL WARNING: DBD::mysql::st execute failed: MySQL server has gone away at configDB.pm line 425.
2022.03.04 11:21:42.333 1:     main::__ANON__                      called by configDB.pm (425)
2022.03.04 11:21:42.333 1:     main::cfgDB_FileWrite               called by configDB.pm (587)
DBD::mysql::st execute failed: MySQL server has gone away at configDB.pm line 425.
2022.03.04 11:21:42.335 1: PERL WARNING: Issuing rollback() due to DESTROY without explicit disconnect() of DBD::mysql::db handle database=fhem_configDB;host=nas;port=3307 at configDB.pm line 425.
2022.03.04 11:21:42.335 1:     main::__ANON__                      called by configDB.pm (425)
2022.03.04 11:21:42.335 1:     (eval)                              called by configDB.pm (425)
2022.03.04 11:21:42.336 1:     main::cfgDB_FileWrite               called by configDB.pm (587)

Du kannst die Attribute wieder zurücksetzen bzw. Löschen.
Eigentlich müssen vor dem Teil, den Du jetzt aus dem Log gepostet hast, noch andere Informationen stehen, die mir mehr geholfen hätten. Aber sei es drum...

Der Fehler passiert beim Schreiben des statefile. Warum, erschließt sich aus dem Logauszug nicht.

Kannst Du mal in die Logs Deines mysql Servers schauen, ob sich dort Hinweise auf den möglichen Grund finden?

Zitat von: betateilchen am 04 März 2022, 11:36:53
Du kannst die Attribute wieder zurücksetzen bzw. Löschen.
Eigentlich müssen vor dem Teil, den Du jetzt aus dem Log gepostet hast, noch andere Informationen stehen, die mir mehr geholfen hätten. Aber sei es drum...

sorry - davor standen nur setstate Einträge, die ich nicht für relevant hielt

2022.03.04 11:21:42.268 4: configDB: setstate zone_Arbeitszimmer 2021-06-25 12:52:40 associatedWith Bewegungsmelder_Arbeitszimmer
2022.03.04 11:21:42.268 4: configDB: setstate zone_Arbeitszimmer 2022-03-03 06:55:29 lastZone timer
2022.03.04 11:21:42.268 4: configDB: setstate zone_Arbeitszimmer 2022-03-03 06:55:29 occupied 0
2022.03.04 11:21:42.268 4: configDB: setstate zone_Arbeitszimmer 2022-03-03 06:55:29 state absent
2022.03.04 11:21:42.269 4: configDB: setstate zone_Kueche likely
2022.03.04 11:21:42.269 4: configDB: setstate zone_Kueche 2021-06-25 13:43:02 associatedWith MQTT2_zigbee_Bewegungsmelder_Kueche
2022.03.04 11:21:42.269 4: configDB: setstate zone_Kueche 2022-03-04 10:37:37 lastZone timer
2022.03.04 11:21:42.269 4: configDB: setstate zone_Kueche 2022-03-04 10:37:37 occupied 80
2022.03.04 11:21:42.269 4: configDB: setstate zone_Kueche 2022-03-04 10:37:37 state likely
2022.03.04 11:21:42.269 4: configDB: setstate zone_Schlafzimmer absent
2022.03.04 11:21:42.270 4: configDB: setstate zone_Schlafzimmer 2021-06-25 13:07:56 associatedWith Bettsensor
2022.03.04 11:21:42.270 4: configDB: setstate zone_Schlafzimmer 2021-07-09 20:56:11 lastZone timer
2022.03.04 11:21:42.270 4: configDB: setstate zone_Schlafzimmer 2021-07-09 20:56:11 occupied 0
2022.03.04 11:21:42.270 4: configDB: setstate zone_Schlafzimmer 2021-07-09 20:56:11 state absent
2022.03.04 11:21:42.270 4: configDB: setstate zone_Wohnzimmer absent
2022.03.04 11:21:42.270 4: configDB: setstate zone_Wohnzimmer 2021-06-25 13:38:44 associatedWith MQTT2_zigbee_Bewegungsmelder_Wohnzimmer
2022.03.04 11:21:42.270 4: configDB: setstate zone_Wohnzimmer 2022-03-04 10:27:39 lastZone timer
2022.03.04 11:21:42.271 4: configDB: setstate zone_Wohnzimmer 2022-03-04 10:27:39 occupied 0
2022.03.04 11:21:42.271 4: configDB: setstate zone_Wohnzimmer 2022-03-04 10:27:39 state absent

Zitat von: betateilchen am 04 März 2022, 11:36:53
Der Fehler passiert beim Schreiben des statefile. Warum, erschließt sich aus dem Logauszug nicht.

Kannst Du mal in die Logs Deines mysql Servers schauen, ob sich dort Hinweise auf den möglichen Grund finden?

also das MariaDB Error Log ist leer

log_error
/var/packages/MariaDB10/target/mysql/Nas.err

Da bei Dir das Schreiben anderer (in der Regel kleinerer) Dateien in die Datenbank problemlos funktioniert, vermute ich den MySQL Server (genauer: dessen Parametrierung) als Ursache für das Problem.

Nach ein bisschen googlen zu Deiner Fehlermeldung habe ich ein paar Ergebnisse gefunden, in denen das Problem (entweder max_packet_size oder timeout) diskutiert wird und in denen sich auch Lösungsansätze finden.

https://www.perlmonks.org/?node_id=150255
https://haydenjames.io/mysql-server-has-gone-away-error-solutions/
https://www.danami.com/clients/knowledgebase/114/How-do-I-fix-the-error-Mysql-Server-has-gone-away.html?language=deutsch

Zitat von: betateilchen am 04 März 2022, 13:08:02
Da bei Dir das Schreiben anderer (in der Regel kleinerer) Dateien in die Datenbank problemlos funktioniert, vermute ich den MySQL Server (genauer: dessen Parametrierung) als Ursache für das Problem.

Nach ein bisschen googlen zu Deiner Fehlermeldung habe ich ein paar Ergebnisse gefunden, in denen das Problem (entweder max_packet_size oder timeout) diskutiert wird und in denen sich auch Lösungsansätze finden.

https://www.perlmonks.org/?node_id=150255
https://haydenjames.io/mysql-server-has-gone-away-error-solutions/
https://www.danami.com/clients/knowledgebase/114/How-do-I-fix-the-error-Mysql-Server-has-gone-away.html?language=deutsch

Hi - danke noch mal für Deine Hilfe und für das Finden für die Lösung. Nachdem ich im SQL Server

[mysqld]
max_allowed_packet=256M

gesetzt hatte, war speichern kein Problem mehr

super, danke für die Rückmeldung!

Kannst Du bitte im ersten Beitrag hier noch ein "[gelöst]" in den Titel schreiben? Danke.