configDB - Fehler bei FHEM Neustart

[fhainz]

Hallo!

Hin und wieder stürzt mein (aktuelles) FHEM beim Neustart ab. Meistens kommt es nach einem Update vor. In der Konsole hab ich dann diesen Fehler:

DBD::mysql::st execute failed: Data too long for column 'content' at row 1 at configDB.pm line 291.
DBD::mysql::st execute failed: Data too long for column 'content' at row 1 at configDB.pm line 291.
Issuing rollback() due to DESTROY without explicit disconnect() of DBD::mysql::db handle database=configDB;host=server.local;port=3306 at configDB.pm line 291.

Hat jemand eine Idee woran das liegt?

Grüße

[betateilchen]

Hat jemand eine Idee woran das liegt?

Im Prinzip ja, aber die Idee passt nicht zu Deiner Aussage, dass nur hin und wieder auftritt.

Der Fehler tritt auf, während versucht wird, irgendeine Datei in die Datenbank zu schreiben, es geht nicht um die Konfiguration oder das Statefile.

Kannst Du bitte mal in Zeil 287 folgendes eintragen:

Log3 (undef, 1,"File: $filename");

dann kannst Du im Logfile herausfinden, bei welcher Datei das passiert.

[fhainz]

Code Auswählen Erweitern

2014.06.09 14:23:59.182 1: File: ./log/eventTypes.txt


Du hast schon recht, sobald ich ein device schalte packt FHEM den Neustart nicht. Nach einen Neustart gleich wieder neustarten funktioniert.

[betateilchen]

Hast Du mal geschaut, wie groß die eventTypes.txt bei Dir ist? Am besten mal mit fileexport exportieren, dann wird die Größe angezeigt.

[fhainz]

65534 bytes written from database into file ./log/eventTypes.txt

Hab die eventTypes.txt mal geleert. Jetzt funktionierts wieder.

[betateilchen]

örks...

Da muss ich wohl mal in die Tiefe gehen und schauen, warum nicht mehr als 65k geschrieben werden können. Danke für den Hinweis.

[fhainz]

Anscheinend passiert das schon ab 61k.

Code Auswählen Erweitern

61428 bytes written from database into file ./log/eventTypes.txt

Gerade ein update gemacht und FHEM hat den Neustart nicht gepackt.


Grüße

[betateilchen]

Das hat aber irgendwie nichts mit der Datenbank selbst zu tun, die kann viel größere Dateien verarbeiten.

Pragmatische Frage: Brauchst Du die eventTypes überhaupt für irgendwas?

[fhainz]

Ja die verwende ich eigentlich schon. Natürlich nicht sehr oft aber hin und wieder sind die zum log optimieren sehr nützlich.

[betateilchen]

Ich glaube, da müssen wir wohl mal Rudi mit ins Boot holen, da er für die eventTypes verantwortlich ist und der Fehler bisher offenbar nur dabei auftritt.

[fhainz]

Ok.
Kannst du das mal im Entwickler forum ansprechen?

[rudolfkoenig]

Die Tabelle wird scheinbar angelegt mit

Code Auswählen Erweitern

CREATE TABLE IF NOT EXISTS fhembinfilesave(filename TEXT, content BLOB)

Google sagt zu "mysql blob size":

A BLOB can be 65535 bytes maximum. If you need more consider using a MEDIUMBLOB for 16777215 bytes or a LONGBLOB for 4294967295 bytes.

Kann dem nichts hinzufuegen.

[betateilchen]

Merkwürdig...

• Offenbar ist die 64k Grenze etwas mysql-spezifisches?
• Ich habe auch größere Dateien als 64kB in meiner (sqlite) configDB
• ausserdem erklärt das auch noch nicht, warum der Fehler schon bei 61xxx Bytes auftritt

NB: Aus der Doku zu sqlite:

The maximum number of bytes in a string or BLOB in SQLite is defined by the preprocessor macro SQLITE_MAX_LENGTH. The default value of this macro is 1 billion (1 thousand million or 1,000,000,000).

[betateilchen]

@fhainz kannst Du mal bitte probieren, ein "alter table fhembinfilesave column content mediumblob" auszuführen?

[fhainz]

• ausserdem erklärt das auch noch nicht, warum der Fehler schon bei 61xxx Bytes auftritt

Da hab ich mich schlecht ausgedrückt. Ich vermutete dass der letzte Fehler beim Neustart auf das Problem mit eventTypes zurückzuführen ist. FHEM läuft normalerweise im Autostart und da sehe ich die Fehler auf der Konsole nicht. Um die Fehlermeldungen zu sehen habe ich damals FHEM manuell gestartet.

@fhainz kannst Du mal bitte probieren, ein "alter table fhembinfilesave column content mediumblob" auszuführen?

Hab ich versucht, bekam aber einen Fehler "error in your mysql Syntax". Habe es dann mit Sequel Pro per Hand geändert.

BTW:
Gabs nicht mal einen Befehl "configdb backup"?