Ich werde noch wahnsinnig....
also: FHEM 5.7 auf Bananapi und Smartvisu sowie mit SQL-DB, läuft seit ca. 8 Monaten stabil... keine Probleme.
In letzter Zeit traten häufiger mal Probleme am angeschlossen 7" Tablett mit Smartvisu auf: "Konnte Host nicht erreichen". Leider weiss ich nicht zu welchem Zeitpunkt das angefangen hat...
Es wurde aber immer mehr. Gestern mal der Sache angenommen, da das Tablett den Bananapi nicht mehr erreichen konnte.
Über die normale WebOberfläche kam ich immer noch mal wieder ran.
Dachte erst es handelt sich um einen Hardwarefehler, aber das konnte nicht bestätigt werden. Platte ok. Auch ist es nicht zu geringer Plattenspeicher, von der 64 GB SSD sind noch ca. 50 GB frei...
Vor lauter Verzweiflung dann ein Update gemacht, sowohl auf BS- als auch auf FHEM Ebene...Soweit so gut, nun startet also FHEM gar nicht mehr...grummel.
Leere Datenbank ausprobiert, läuft. Ok, also irgendein Konfig-Problem?! Verbose - Level Global auf 5 gesetzt, FHEM gestartet, bis Absturz gewartet, LOG File abgelesen - nichts. Keine Besonderheiten drin, es hört einfach auf. Mehrfach getestet...keine Änderung.
Nun will ich nicht meine Konfiguration komplett Stück für Stück neu anlegen müssen...da habe ich keinen Nerv und vor allem keine Zeit zu.
Hat sich im Handling für Config-DB oder sonstige wichtige Dinge irgendetwas wichtiges geändert was zu solchen Problemen führen könnte ?
Ich stehe auf dem Schlauch...im Forum bin ich nicht wirklich fündig geworden, ist aber auch schwierig wenn man nicht genau weiss wonach man suchen muss.
Need help.
Grüße Marie
Hallo Marie,
Bitte gib mal hier das Logfile bekannt. Es klingt erstmal so als würde er die DB korrekt einlesen können und hat dann bei genau einem define eines Devices Probleme. Default ist ja Log 3 aktiv, jetzt weiß ich dummerweise nicht wie man das Log höher drehen kann mit configDB. Eventuell kann da Udo (betateilchen) was zu sagen.
Grüße
Hallo Cool,
das Log hatte ich schon auf 5 gestellt...brachte aber nichts sichtbares erst einmal. Ich muss das mal aufs wichtigste beschränken und schicke es dann mal hoch...
Es ist zum Mäusemelken..Welches Device könnte den n dafür sorgen das FHEM nicht mehr startet ???
Grüße
Hihi,
Du bist ja Süß. Ich kenne da leider Deine Umgebung nicht. Was mir gerade ein fällt ich habe was von configDB geschrieben. Dabei weiß ich gar nicht ob Du die hast. Oder nimmst Du config.cfg?
Dann schau im Log welches Devices als letztes aufgerufen wurde und trage das in der Konfig darauf folgende Device mal aus.
Eine Alternative ist fhem mit strace zu starten (strace -f -o /tmp/strace.out fhem.pl fhem.cfg)
Das ist ja super Rudi. Danke Dir für den Tip.
Grüße
Hallo,
die Frage nach dem Device war auch eher rhetorisch...schon klar das Du mir das nicht sagen kannst...
Stellt sich nur die Frage ob ein Device grundsätzlich die Möglichkeit hat dafür zu sorgen das FHEM nicht mehr startet....
Zitat von: rudolfkoenig am 14 Juni 2016, 17:13:07Eine Alternative ist fhem mit strace zu starten (strace -f -o /tmp/strace.out fhem.pl fhem.cfg)
Geht das auch mit der ConfigDB ? Und wie darf dann der Befehl lauten?
LG
Marie
By the way: ich habe den Befehl mal mit der fhem.cfg probiert, da ich die Datei ja auch noch habe...aber selbst wenn ich in dem Verzeichnis den Befehl ausführe, wo sich fhem.pl befindet, bekomme ich die Meldung
"strace: Can't stat 'fhem.pl': No such file or directory"
Strace funktioniert unabhaengig vom fhemcfg/fhem.db.
Das Befehl muss vmtl. lauten "strace -f -o /tmp/strace.out perl fhem.pl fhem.cfg" oder "strace -f -o /tmp/strace.out ./fhem.pl fhem.cfg", halt so, wie man fhem.pl auch sonst, ohne strace, zum Laufen kriegt.
strace -f -o /tmp/strace.out fhem.pl configDB.cfg
Zitat von: CoolTux am 14 Juni 2016, 18:41:14
strace -f -o /tmp/strace.out fhem.pl configDB.cfg
ich geh mal Popcorn holen...
Vermutlich meintest Du
strace -f -o /tmp/strace.out fhem.pl configDB
wobei ich nicht sicher bin, ob nicht der Aufruf von perl selbst noch fehlt.
Aber was mich für die Fehlereingrenzung viel mehr interessieren würde: Im Eingangspost steht "Update auf Betriebssystemebene gemacht" Nun wäre interessant, welche perl Version auf der Plattform läuft.
perl -v
Zitat von: CoolTux am 14 Juni 2016, 18:41:14
strace -f -o /tmp/strace.out fhem.pl configDB.cfg
Ich vermute mal das heisst dann
strace -f -o /tmp/strace.out fhem.pl configDB.db
Da hat betateilchen ein wenig eher als ich gepostet....der Aufruf mit .db am Ende geht...allerdings geht dann nach einiger Zeit strace "out of memory" ?!
Da meine Perl-Kenntnisse doch etwas beschränkt sind, kann ich mit dem trace nur bedingt etwas anfangen. gibt es etwas auf das ich achten muss? Oder wer mag mal seine Kenntnisse zur Verfügung stellen?
@betateilchen: perl 5.18.2
...und ich geh dann mal Popcorn für Dich holen... ;-)
Grüße
Zitat von: betateilchen am 14 Juni 2016, 18:46:28
ich geh mal Popcorn holen...
Vermutlich meintest Du
strace -f -o /tmp/strace.out fhem.pl configDB
wobei ich nicht sicher bin, ob nicht der Aufruf von perl selbst noch fehlt.
Aber was mich für die Fehlereingrenzung viel mehr interessieren würde: Im Eingangspost steht "Update auf Betriebssystemebene gemacht" Nun wäre interessant, welche perl Version auf der Plattform läuft.
perl -v
Hast natürlich Recht. Sorry Udo. War mit Kind auf dem Spielplatz und bisschen abgelenkt.
Marie hat mir ein Log gesendet weil zu viel persönlich dazu steht. Was ich sehen konnte war das eine Menge Fehler in Verbindung mit 99_myUtils war.
Global symbol "%FW_webArgs" requires explicit package name at ./FHEM/99_MyUtils.pm line 34.
Mein Verdacht ist die Umstellung auf 5.7. Was denkt ihr. Udo ich spendiere Dir ne Packung Popcorn wenn Du helfen magst ;)
Grüße
Habe die 99_myUtils.pm mal umbenannt und versucht zu starten aber das war nix. Ändert nichts an der Tatsache.
Hatte auch schon vorher 5.7 drauf, hab mal eben geschaut, auf meinem zweiten FHEM - Raspberry läuft auch schon 5.7 und die waren beide auf dem gleichen Stand.
Aber vielleicht hängt das ja auch dem letzten Update wirklich damit zusammen irgendwie....
Gruss
Mal anders gedacht.. wie groß ist Deine DB?
Und was genau wurde upgedatet. Also erstmal FHEM mal bitte unter restoreDir schauen im letzten Datum schauen.
Also habe noch einmal geschaut,
die Fehlermeldungen bzgl. der 99_myUtils sind dann auch weg im Log wenn ich sie umbenenne.
Die configDB ist schon ziemlich gross, ca.182 MB...ich werde sie mal testweise verkleinern....
Grüße
Zitat von: Marie am 14 Juni 2016, 19:00:15
der Aufruf mit .db am Ende geht
Das geht, aber fhem funktioniert dann nicht. Glaub mir, da gehört KEIN .db ans Ende!
Wie kann man denn eine configDB mit 182 MB produzieren?
Mach mal ein
configdb reorg 10und poste die Ausgabe.
Das kann sie glaube nicht Udo. Ihr FHEM startet nicht!!!
@beta: ja stimmt, ohne .db gehts.
Und die DB? Tja, frag mal das System....die habe ich mir ja nicht ausgedacht...sind halt schon einige alte Konfigs drin denke ich...
Gruß
Zitat von: CoolTux am 14 Juni 2016, 20:28:04
Das kann sie glaube nicht Udo. Ihr FHEM startet nicht!!!
Stimmt!
es muss doch irgendwas im Logfile stehen, warum fhem nicht startet. Das kann nicht nur an der 99_myUtils.pm liegen.
Zitat von: betateilchen am 14 Juni 2016, 20:25:03
Wie kann man denn eine configDB mit 182 MB produzieren?
Geht schon: Meine hat auch 200MB. ;D
Habe aktuell 25 Versionen in der DB und einige Files (auch einige Images)
Sollte aber grundsätzlich auch kein Problem sein, oder?
nein, ein Problem ist das an sich nicht.
Autsch, habe gerade mal geschaut. 232Mb. Räume gerade auf. Kann es sein das das ewig dauert. Meiner rödelt schon 10 min und das ganze fhem steht ;D
Bei mir waren nur 6 Versionen drin...
habe dann mal aber die vorletzte Version aus dem Backup eingespielt und FHEM läuft wieder...und nun mal sukzessive Approximation betreiben...
Grüße
PS: Aber nicht mehr heute, keine Lust mehr...
Danke @ all für Eure Hilfe, ich melde mich falls ich herausfinde wo das Problem liegt...
Zitat von: Marie am 14 Juni 2016, 20:45:54
habe dann mal aber die vorletzte Version aus dem Backup eingespielt und FHEM läuft wieder
Na das ist doch mal das Wichtigste.
-----------------------------------------------------------------
configDB Database Information
-----------------------------------------------------------------
# $Id: configDB.pm 11560 2016-05-29 19:46:13Z betateilchen $
-----------------------------------------------------------------
dbconn: SQLite:dbname=/opt/fhem/sqldb/configDB.db
dbtype: SQLITE
-----------------------------------------------------------------
config: 8768 entries
Ver 0 saved: Tue Jun 14 20:51:27 2016 def: 377 attr: 1815
Ver 1 saved: Tue Jun 14 20:48:28 2016 def: 377 attr: 1814
Ver 2 saved: Tue Jun 14 20:47:18 2016 def: 377 attr: 1814
Ver 3 saved: Tue Jun 14 20:45:51 2016 def: 377 attr: 1813
-----------------------------------------------------------------
state: 1460 entries saved: Tue Jun 14 20:51:24 2016
-----------------------------------------------------------------
filesave: 86 files stored in database
-----------------------------------------------------------------
-rwxr-xr-x 1 fhem dialout 7,5M Jun 14 20:51 configDB.db
-----------------------------------------------------------------
configDB Database Information
-----------------------------------------------------------------
# $Id: configDB.pm 11560 2016-05-29 19:46:13Z betateilchen $
-----------------------------------------------------------------
dbconn: mysql:database=fhemConfigDB;host=localhost;port=3306
dbuser:
dbpass:
dbtype: MYSQL
-----------------------------------------------------------------
config: 36866 entries
Ver 0 saved: Tue Jun 14 07:19:31 2016 def: 501 attr: 2849
Ver 1 saved: Mon Jun 13 06:31:27 2016 def: 501 attr: 2849
Ver 2 saved: Mon Jun 13 06:24:53 2016 def: 501 attr: 2849
Ver 3 saved: Sun Jun 12 21:54:30 2016 def: 501 attr: 2849
Ver 4 saved: Sat Jun 11 14:28:49 2016 def: 501 attr: 2849
Ver 5 saved: Sat Jun 11 13:33:11 2016 def: 501 attr: 2849
Ver 6 saved: Sat Jun 11 13:32:10 2016 def: 502 attr: 2849
Ver 7 saved: Sat Jun 11 13:27:25 2016 def: 502 attr: 2849
Ver 8 saved: Sat Jun 11 13:24:24 2016 def: 502 attr: 2849
Ver 9 saved: Sat Jun 11 13:20:46 2016 def: 502 attr: 2849
Ver 10 saved: Sat Jun 11 13:15:03 2016 def: 502 attr: 2849
-----------------------------------------------------------------
state: 5900 entries saved: Tue Jun 14 07:19:25 2016
-----------------------------------------------------------------
filesave: 31 files stored in database
-----------------------------------------------------------------
232M Jun 14 20:50 fhemconfig.ibd
-----------------------------------------------------------------
configDB Database Information
-----------------------------------------------------------------
# $Id: configDB.pm 11560 2016-05-29 19:46:13Z betateilchen $
-----------------------------------------------------------------
dbconn: SQLite:dbname=/opt/fhem/configDB.db
dbtype: SQLITE
-----------------------------------------------------------------
max Versions: 25
config: 149877 entries
Ver 0 saved: Sat Jun 11 05:17:33 2016 def: 773 attr: 5019
Ver 1 saved: Fri Jun 10 22:50:04 2016 def: 773 attr: 5012
Ver 2 saved: Tue Jun 7 08:47:36 2016 def: 772 attr: 5008
Ver 3 saved: Tue Jun 7 08:45:56 2016 def: 772 attr: 5007
Ver 4 saved: Tue Jun 7 07:05:06 2016 def: 772 attr: 5006
Ver 5 saved: Mon Jun 6 09:45:47 2016 def: 771 attr: 5002
Ver 6 saved: Mon Jun 6 09:35:51 2016 def: 771 attr: 5002
Ver 7 saved: Mon Jun 6 09:32:28 2016 def: 771 attr: 5002
Ver 8 saved: Mon Jun 6 08:29:34 2016 def: 771 attr: 5002
Ver 9 saved: Mon Jun 6 08:28:36 2016 def: 771 attr: 5002
Ver 10 saved: Mon Jun 6 08:22:43 2016 def: 771 attr: 5001
Ver 11 saved: Mon Jun 6 08:08:10 2016 def: 771 attr: 5000
Ver 12 saved: Mon Jun 6 07:52:29 2016 def: 771 attr: 4999
Ver 13 saved: Fri Jun 3 23:18:18 2016 def: 770 attr: 4992
Ver 14 saved: Fri Jun 3 22:45:50 2016 def: 769 attr: 4990
Ver 15 saved: Fri Jun 3 16:31:38 2016 def: 769 attr: 4990
Ver 16 saved: Thu Jun 2 18:40:03 2016 def: 767 attr: 4986
Ver 17 saved: Thu Jun 2 10:24:37 2016 def: 767 attr: 4986
Ver 18 saved: Tue May 31 22:33:16 2016 def: 767 attr: 4986
Ver 19 saved: Tue May 31 17:59:18 2016 def: 767 attr: 4985
Ver 20 saved: Wed May 25 14:57:15 2016 def: 766 attr: 4981
Ver 21 saved: Tue May 24 21:50:08 2016 def: 766 attr: 4979
Ver 22 saved: Mon May 23 22:08:38 2016 def: 766 attr: 4979
Ver 23 saved: Mon May 23 22:01:35 2016 def: 766 attr: 4978
Ver 24 saved: Mon May 23 22:00:16 2016 def: 766 attr: 4978
Ver 25 saved: Mon May 23 21:55:37 2016 def: 766 attr: 4977
-----------------------------------------------------------------
state: 8916 entries saved: Sat Jun 11 05:17:33 2016
-----------------------------------------------------------------
filesave: 72 files stored in database
-----------------------------------------------------------------
200M Jun 14 11:38 configDB.db
Bei mir sind es nur 9212 Entries und max 6 Versionen...dafür aber 182 MB...
Kenn mich jetzt nicht sooo mit SQL-Light aus, aber auffällig ist:
User Einträge DB-Größe
------------------------------------------------
betateilchen 8768 7,5M
CoolTux 36866 232M
Benni 149877 200M
Marie 9212 182M
Meines Wissens sollte man "hin und wieder" bei SQL-light die DB "optimieren", vor allem nach größeren "Löschvorgängen". Fragt mich bitte jetzt nur nicht wie ...
Naja, ganz so einfach ist das nicht. Du weisst ja nicht was noch alles mit in der DB an binär Files drin steckt. ;D
Doch, es ist eigentlich ganz einfach, wenn man sich an die Vorschläge hält, die in der commandref stehen.
Und mit gespeicherten Binärdateien in der Datenbank hat das überhaupt nichts zu tun. ;)
Create an empty database, e.g. with sqlite3:
mba:fhem udo$ sqlite3 configDB.db
SQLite version 3.7.13 2012-07-17 17:46:21
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> pragma auto_vacuum=2;
sqlite> .quit
mba:fhem udo$
Das Entscheidendene ist das pragma auto_vacuum=2, das dafür sorgt, dass die Datenbank durch eine Löschung auch tatsächlich kleiner wird. Das Beispiel bezieht sich auf sqlite wo das extrem wichtig ist. Denn ansonsten wird die Datenbank einfach weitergeschrieben und das sqlite-File dadurch immer größer (übrigens nicht nur für configDB relevant, sondern auch bei DbLog)
Wie andere Datenbanksysteme das handhaben, weiß ich nicht so genau.
Ich habe keine Erfahrung mit auto_vacuum, aber interessiert (nicht wg. FHEM, da setze ich weiterhin auf fhem.cfg), und wuerde gerne wissen, welche der beiden Aussagen richtig ist:
ZitatDas Entscheidendene ist das pragma auto_vacuum=2, das dafür sorgt, dass die Datenbank durch eine Löschung auch tatsächlich kleiner wird.
https://www.sqlite.org/pragma.html#pragma_auto_vacuum
ZitatWhen the value of auto-vacuum is 2 or "incremental" then the additional information needed to do auto-vacuuming is stored in the database file but auto-vacuuming does not occur automatically at each commit as it does with auto_vacuum=full. In incremental mode, the separate incremental_vacuum (https://www.sqlite.org/pragma.html#pragma_incremental_vacuum) pragma must be invoked to cause the auto-vacuum to occur.
Aller guten Dinge sind drei:
Zitat
Auto-VACCUM
SQLite Auto-VACUUM does not do the same as VACUUM rather it only moves free pages to the end of the database thereby reducing the database size. By doing so it can significantly fragment the database while VACUUM ensures defragmentation. So Auto-VACUUM just keeps the database small.
Und dass die Datenbank tatsächlich klein bleibt, ist ja in der vorangegangenen Tabelle von Werniemann eindeutig belegt.
(auto_vacuum=2 und auto_vacuum=full sind in diesem Zusammenhang äquivalent)Zitat von: rudolfkoenig am 15 Juni 2016, 10:39:22
nicht wg. FHEM, da setze ich weiterhin auf fhem.cfg
ach Rudi... :)
Zitatauto_vacuum=2 und auto_vacuum=full sind in diesem Zusammenhang äquivalent
Laut sqlite Doku ist 2=incremental, und 1=full
Deswegen meine Verwirrung.
Komm, jetzt verwirren wir die Anwender endgültig...
Du hast völlig recht: 1 = FULL, 2 = INCREMENTAL
Aber: mit "äquivalent" meinte ich, dass es im "Einsatzfall" der configDB egal ist, ob man das mit 1 oder 2 setzt, da configDB nicht mit einer permanent geöffneten Datenbank arbeitet und es deshalb egal ist, ob eine auto_vacuum (also das Verschieben von leerem Speicherplatz an das Ende der Datenbank) nach jedem commit (auto_vacuum=1) ausgeführt wird oder nicht (auto_vacuum=2). Ein gesetztes auto_vacuum findet auf jeden Fall beim Schließen der Datenbankverbindung statt.
Sorry für die Verwirrung, ich hatte mich wirklich unglücklich ausgedrückt. Vielleicht hätte ich statt "äquivalent" besser "egal" schreiben sollen.
Bei anderen Datenbnken wird es im "Prinzip" ähnlich gemacht. Allerdings kümmert sich der Server (meistens) um das automatische Aufräumen. Nur in Extremfällen wie z.B. löschen vieler Daten (oder Platzmangel auf der HDD) macht man ein optimieren der Datenbankfiles.
Allerdings kann es bei mysql unter Umständen besser sein, nicht zu optimieren ... allerdings nur für (für fhem uninteressante) Havy-Load-DBs
Aber als Kurzfasung:
Wenn ich mir betateilchens DB-Daten und die der anderen ansehe (und anderer Informationen), würe ich auf jedem Falle die DBs optimieren. Und wenn, wie CoolTux angedeutet, mehr in der DB steht, sollte man erst recht optimieren ...