Nach dem heutigen Update und dem notwendigen Shutdown + Restart startet FHEM nicht mehr. Im FHEM Logfile finden sich die folgenden Zeilen wieder.
2014.05.02 08:56:58 1: update A new version of fhem.pl was installed, 'shutdown restart' is required!
2014.05.02 08:57:33 0: Server shutdown
DBD::SQLite::st execute failed: database is locked at configDB.pm line 416.
DBD::SQLite::st execute failed: database is locked at configDB.pm line 416.
Issuing rollback() due to DESTROY without explicit disconnect() of DBD::SQLite::db handle dbname=/opt/fhem/configDB.db at configDB.pm line 416.
Issuing rollback() due to DESTROY without explicit disconnect() of DBD::SQLite::db handle dbname=/opt/fhem/configDB.db at configDB.pm line 416.
Danach kommt nichts mehr.
Geh mal auf die Systemkonsole und mach ein "fuser /opt/fhem/configDB.db"
Da sollte eine Antwort kommen, die ungefähr so aussieht: "configDB.db: 5430"
5430 ist die PID des Prozesses, der die Datenbank sperrt. Den kannst Du dann mit "kill -9 5430" abschießen.
Aber eigentlich gibt es in fhem gar keine Prozesse, die die configDB sperren können...
Ich habe jetzt ein wenig testen können, ist ja Brückentag.
Zuerst habe ich das System auf den Zustand vor dem Update zurück gesetzt. Damit läuft FHEM wieder. Dann noch einmal das Update gestartet. Beim Neustart von FHEM dann wieder gleicher Fehler.
configDB wird von keinem Prozess genutzt. Zur Überprüfung habe ich noch die Datenbank von DbLog geprüft. Diese wird von perl genutzt. Prüfe ich die Nutzung von configDB gleich nach dem Neustart, wird sie bis zum Abbruch auch von perl genutzt.
Meine aktuell laufenden Versionen sind:
# $Id: fhem.pl 5632 2014-04-24 19:16:01Z rudolfkoenig $
# $Id: configDB.pm 5643 2014-04-25 15:55:04Z betateilchen $
Meine aktuellen - problemlos funktionierenden - Versionen:
# $Id: fhem.pl 5715 2014-05-01 15:02:06Z rudolfkoenig $
# $Id: configDB.pm 5697 2014-04-29 18:06:04Z betateilchen $
Welche Module hast Du sonst noch im Einsatz?
Es gibt eigentlich keinen Prozess aus fhem heraus, der die Datenbank sperren kann. Die Datenbank wird bei Bedarf geöffnet, die benötigten Daten werden gelesen und dann wird die Datenbank wieder geschlossen. Es gibt keine dauerhaft bestehende offene Datenbankverbindung.
Dies sind meine geladenen Module.
# $Id: fhem.pl 5632 2014-04-24 19:16:01Z rudolfkoenig $
# $Id: configDB.pm 5643 2014-04-25 15:55:04Z betateilchen $
# $Id: 00_CUL.pm 5487 2014-04-08 11:29:41Z rudolfkoenig $
# $Id: 09_CUL_FHTTK.pm 5207 2014-03-12 19:05:33Z matscher $
# $Id: 14_CUL_TX.pm 4229 2013-11-15 17:29:55Z rudolfkoenig $
# $Id: 14_CUL_WS.pm 5379 2014-03-30 16:34:01Z rudolfkoenig $
# $Id: 93_DbLog.pm 5646 2014-04-25 18:03:29Z tobiasfaust $
# $Id: 64_ESA2000.pm 3778 2013-08-24 13:49:54Z stromer-12 $
# $Id: 01_FHEMWEB.pm 5627 2014-04-24 10:48:11Z rudolfkoenig $
# $Id: 11_FHT.pm 5070 2014-02-28 07:48:55Z rudolfkoenig $
# $Id: 10_FS20.pm 5326 2014-03-26 07:15:25Z rudolfkoenig $
# $Id: 92_FileLog.pm 5452 2014-04-06 06:24:47Z rudolfkoenig $
# $Id: 12_HMS.pm 5097 2014-03-02 15:25:08Z rudolfkoenig $
# $Id: 98_Heating_Control.pm 5555 2014-04-18 16:33:07Z dietmar63 $
# $Id: 13_KS300.pm 5545 2014-04-17 20:08:54Z rudolfkoenig $
# $Id: 73_PRESENCE.pm 5434 2014-04-04 15:43:23Z markusbloch $
# $Id: 99_SUNRISE_EL.pm 4537 2014-01-03 08:28:59Z rudolfkoenig $
# $Id: 98_SVG.pm 5607 2014-04-23 10:48:59Z rudolfkoenig $
# $Id: 32_SYSSTAT.pm 5427 2014-04-04 06:56:59Z justme1968 $
# $Id: 59_Twilight.pm 5519 2014-04-13 19:17:22Z dietmar63 $
# $Id: 99_Utils.pm 5488 2014-04-08 11:32:17Z rudolfkoenig $
# $Id: 59_Weather.pm 4887 2014-02-11 19:27:08Z borisneubert $
# $Id: 98_XmlList.pm 2895 2013-03-11 19:48:01Z rudolfkoenig $
# $Id: 90_at.pm 5319 2014-03-25 10:11:47Z rudolfkoenig $
# $Id: 98_cmdalias.pm 3738 2013-08-18 14:13:59Z rudolfkoenig $
# $Id: 98_dewpoint.pm 5099 2014-03-02 16:29:34Z betateilchen $
# $Id: 95_holiday.pm 5606 2014-04-23 10:44:26Z rudolfkoenig $
# $Id: 91_notify.pm 5470 2014-04-07 08:32:35Z rudolfkoenig $
# $Id: 33_readingsGroup.pm 5414 2014-04-02 11:55:24Z justme1968 $
# $Id: 32_speedtest.pm 4756 2014-01-27 21:15:50Z justme1968 $
# $Id: 98_telnet.pm 4844 2014-02-08 07:54:03Z rudolfkoenig $
# $Id: 98_weblink.pm 5608 2014-04-23 10:57:16Z rudolfkoenig $
Am Betriebssystem kann es ja nicht liegen, mit dem derzeitigen FHEM läuft es ja. Sage Bescheid, wenn noch mehr Informationen benötigt werden.
Ich habe noch etwas versucht.
Wenn ich nur die Dateien
fhem.pl
configDB.pm
98_configdb.pm
aktualisiere, tritt der Fehler bereits auf.
Rudi konnte heute den gleichen Fehler reproduzieren, wenn er mit einer neuen (leeren) sqlite-Datenbank versucht hat, fhem zu starten.
Normalerweise wird dabei die Datenbank mit default-Werten automatisch gefüllt, damit fhem starten kann.
Ich kann den Fehler aber auch mit einer neu angelegten leeren Datenbank nicht erzeugen.
Kannst Du mir mal bitte beschreiben, was Du genau gemacht hast, um den Fehler zu bekommen?
Welche DBD/DBI Version hast Du im Einsatz?
Ich habe die DB zweimal angelegt, einmal auf einem aktuellen OSX mit frisch installierten SQLite Perl Modulen und einmal auf einen alten Linux (Ubuntu 10.4). Probleme bekam ich mit beiden Versionen, und ich habe die angelegten DBs auch ueber Kreuz getestet.
configDB.pm wie in commandref.html erzeugt, und "perl fhem.pl configDB" aufgerufen.
Zum Import/etc kam ich gar nicht.
ich habe gerade auf einem aktuellen Mac OSX die Datenbank neu angelegt (und auf einem Debian auf Raspberry) und konnte in beiden Fällen problemlos fhem starten.
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$
MBA:fhem udo$ perl fhem.pl configDB
MBA:fhem udo$
Spannend. Exakt so habe ich es auch gemacht, und ueber 10 mal versucht zu starten.
Und gerade eben wiederholt (mit copy&pste von deinem Text), mit dem gleichen Ergebnis.
Erst das erwaehnte commit() hat geholfen.
Das scheint offenbar ein Problem mit unterschiedlichen Versionen der DBD/DBI Treiber in perl (ausserhalb von fhem) zu sein.
Wenn in fhem eine leere configDB Datenbank entdeckt wird, wird eine Initialversion angelegt, die eine uuid braucht. Zum Ermitteln der uuid wird die Datenbank benutzt. Die Funktion zum Ermitteln benutzt einen eigenen db_connect, und das scheitert, da es bereits eine offene Verbindung gibt.
Ich habe jetzt das commit() an der genannten Stelle eingebaut und bei mir funktioniert auch jetzt noch alles wie vorher.
@dlehmann69 warum das Problem aber mit den updates zusammenhängt, kann ich Dir nicht sagen. Ich habe an dieser Stelle seit langer Zeit nichts mehr geändert. Teste mal bitte mit der hier angehängten Version der configDB.pm und berichte, ob das Problem dann noch auftritt.
Das funktioniert jetzt wieder mit der aktuellen fhem.pl zusammen. Meine Versionen sind jetzt
# $Id: fhem.pl 5728 2014-05-03 09:41:12Z rudolfkoenig $
# $Id: configDB.pm 5721 2014-05-02 17:16:55Z betateilchen $
Ich hatte zuerst in FHEM ein Update gestartet. Da wurden auch die fhem.pl und die configDB.pm aktualisiert. Danach habe ich den notwendigen restart durchgeführt. Und dann kam der Fehler. Dann habe ich FHEM auf den Stand vor dem Update zurückgesetzt. Das funktionierte wieder. Dann habe ich zum Test nur die fhem.pl und die configDB.pm aktualisiert und neu gestartet. Der Fehler trat wieder auf. Jetzt habe ich wieder die beiden genannten Dateien aktualisiert. Die fhem.pl aus dem SVN und die configDB.pm hier aus dem Forum. Das läuft jetzt wieder mit meiner Datenbank. :)
Danke für die Info. Trotzdem bleibt es mir sehr suspekt, warum dieser Fehler nun plötzlich bei einigen Anwendern auftrat.
Wenn Du heute ein update machst, sollten diese beiden Versionen aktuell sein:
# $Id: fhem.pl 5728 2014-05-03 09:41:12Z rudolfkoenig $
# $Id: configDB.pm 5732 2014-05-03 12:00:31Z betateilchen $
und das sollte auch bei Dir funktionieren, denn in dieser configDB steckt die Änderung bereits drin.
Ich habe das Update heute eben durchgeführt. Es hat alles funktioniert. Die beiden Dateien sind mit den erwähnten Versionen aktuell. Und auch der anschließende Neustart hat funktioniert.
Beste Dank nochmal. :)