Fhem stürzt regelmäßig ab.

[Hi2Helmi]

Hallo,
Fhem läuft bei mir schon seit längerem Problemlos. Doch seit ein paar Tagen ist es nicht mehr zuverlässig. Ich habe eigentlich nichts neues gemacht. Wenn Fhem läuft ist alles in Ordnung, das Problem tritt erst dann auf, wenn ich die Oberfläche über meinen Browser aufrufe. Manchmal funktioniert Fhem dann noch ein paar Minuten, manchmal ist es auch nach ein paar Sekunden schon weg.
Fhem kommt dann erst nach einem Neustart vom Pi wieder, während dieser mit SSH immer erreichbar bleibt.
Das einzigste was ich gemacht habe, ich habe ein Fhem-Update eingespielt und den Pi auch upgedatet.
Ich weiß leider nicht, woran es liegen könnte, und auch nicht wie ich heraus finde welches Modul mein Fhem abstürzen lässt.

Bin für jeden Tip dankbar.

[betateilchen]

und was steht im Logfile zum Zeitpunkt des Absturzes?

[Hi2Helmi]

Im Moment des Absturzes gab es keine Meldung, doch nach dem Reboot war die erste Meldung:

Code Auswählen Erweitern

2017.12.24 10:48:09 2: DbLog temp.hum.log -> Error table history - DBD::SQLite::st execute_array failed: database is locked [err was 5 now 2000000000]
executing 1 generated 1 errors at ./FHEM/93_DbLog.pm line 1519.
Da stimmt anscheinend was mit meiner Datenbank nicht. Habe ich noch gar nicht gemerkt.

Habe noch einen andren Fehler gefunden:

Code Auswählen Erweitern

2017.12.24 10:48:50 1: usb create starting
2017.12.24 10:48:50 3: Probing CUL device /dev/ttyS0
2017.12.24 10:48:50 1: PERL WARNING: can't getattr: Eingabe-/Ausgabefehler at FHEM/DevIo.pm line 394.
2017.12.24 10:48:50 3: Can't open /dev/ttyS0: Eingabe-/Ausgabefehler
2017.12.24 10:48:50 1: usb create end

[Otto123]

Hallo Florian,

ob das mit deinem Absturz zusammenhängt weiß ich nicht (wahrscheinlich nicht) aber den initialusbcheck brauchst Du normalerweise nicht, daher rührt aber der zweite "Fehler" im Log. Mach bitte

Code Auswählen Erweitern

attr initialUsbCheck disable 1und vergiß danach ein save config nicht.

Schöne Weihnachten
Otto

[Hi2Helmi]

Ich habe gestern von ca. 11 Uhr bis jetzt die Oberfläche nicht geöffnet und Fhem lief durch ohne Absturz. Heute Früh habe ich dann mal mit einem anderen Browser die Oberfläche geöffnet und nach gefühlten 10 Clicks mit der Maus ist Fhem ausgestiegen und jetzt auch mit meinem Ursprünglichen Browser nicht mehr zu erreichen.
Wurde letzte Woche etwas an der Oberfläche verändert und mit einem Update verteilt, dass ich jetzt plötzlich solch ein Verhalten habe?

[Wernieman]

Wenn Dir FHEM abstürzt, sind dann auch die Prozesse weg?

Also per ssh:

Code Auswählen Erweitern

ps aux | grep [f][hem

Kannst Du fhem durch wiederbeleben aus der Konsole herraus starten? Glaube nicht, das Du jedes Mal den Pi neu starten musst ... das ist eher die "Windowslösung"

[Vista]

Guten morgen. Ich hatte mal ein Problem dass sehr ähnliche Symptome zu Tage gebracht hatte.
Bei mir war die SD Karte kaputt.
Vielleicht mal testweise ein Backup auf ne neue SD einspielen und testen.

PS: falls dein System überhaupt auf einer SD läuft

Gesendet von meinem FRD-L09 mit Tapatalk

[persching]

Auch bei mir läuft seit ein paar Tagen fhem nicht mehr richtig. Und zwar immer dann, wenn ich in der Weboberfläche eine Seite mit einem gplot aufrufe stürzt fhem ab. Wenn ich die Oberfläche nicht aufrufe, dann läuft alles perfekt. Mit

Code Auswählen Erweitern

service fhem stop und

Code Auswählen Erweitern

service fhem start kann ich fhem wieder starten. Die SD Karte kann bei mir nicht kaputt sein, weil mein fhem auf einem bananapi mit internem Flashspeicher läuft.
Ich habe folgende Zeile im Logfile im Verdacht, weil die immer kurz vor dem Absturz im Logfile steht:

2017.12.25 10:26:30 1: PERL WARNING: DBD::SQLite::st execute failed: database is locked at configDB.pm line 407.
DBD::SQLite::st execute failed: database is locked at configDB.pm line 407.

Ich hab mir die configDB.pm in der Zeile 407 angesehen, aber ich kann damit nichts anfangen:

if ($configDB{cache}{$filename} && $configDB{attr}{useCache}) {
      Log3(undef, 4, "configDB serving from cache: $filename");
      return (undef,split(/\n/,$configDB{cache}{$filename}));
    }

   Log3(undef, 4, "configDB reading file: $filename");
   my ($err, @ret, $counter);
   my $fhem_dbh = _cfgDB_Connect;
   my $sth = $fhem_dbh->prepare( "SELECT content FROM fhemb64filesave WHERE filename LIKE '$filename'" );
   $sth->execute();
   my $blobContent = $sth->fetchrow_array();
   $sth->finish();
   $fhem_dbh->disconnect();
   $blobContent = decode_base64($blobContent) if ($blobContent);
   $counter = length($blobContent);

Die rote Zeile ist 407. Könnte es sich hier um das Gleiche Problem handeln? Ich kann leider kein altes Backup einspielen, weil bereits alle Backups den Fehler aufweisen. Ich musste feststellen, dass 5 tägliche Backups zu wenige sind. Ich muss länger in die Vergangenheit schauen. Was ich aber sagen kann: ich denke es liegt nicht an der configDB.db. Diese Datei hab ich von Anfang des Jahres von einem SQL-Dump wiederhergestellt und die weißt die selben Fehler auf.

[Hi2Helmi]

Hallo.
Die SD-Karte kann ich mir weniger vorstellen, da dann Fhem doch auch abstürzen müsste wenn ich die Oberfläche nicht aufrufe und dann wäre doch der Pi über SSH auch nicht mehr erreichbar. Oder liege ich falsch.
Bei mir stürzt Fhem ab wenn auf der Oberfläche bin unabhängig ob ein Plot auf der angezeigten Seite ist oder nicht.
Mit der Konsole kann ich Fhem nicht wieder reanimieren:

Code Auswählen Erweitern

pi@fhem:~ $ ps aux | grep fhem
avahi      470  0.0  0.2   3872  2500 ?        Ss   09:07   0:00 avahi-daemon: running [fhem.local]
fhem      1151  3.7  7.9  80436 75640 pts/0    S    11:09   0:23 perl fhem.pl fhem.cfg
pi        1291  0.0  0.1   4296  1848 pts/0    S+   11:19   0:00 grep --color=auto fhem
pi@fhem:~ $ sudo /etc/init.d/fhem status
fhem is running
pi@fhem:~ $ sudo /etc/init.d/fhem stop
Stopping fhem...
pi@fhem:~ $ ps aux | grep fhem
avahi      470  0.0  0.2   3872  2500 ?        Ss   09:07   0:00 avahi-daemon: running [fhem.local]
fhem      1151  3.4  7.9  80436 75640 pts/0    S    11:09   0:23 perl fhem.pl fhem.cfg
pi        1328  0.0  0.2   4296  1948 pts/0    S+   11:20   0:00 grep --color=auto fhem
pi@fhem:~ $ sudo /etc/init.d/fhem start
Starting fhem...
pi@fhem:~ $ ps aux | grep fhem
avahi      470  0.0  0.2   3872  2500 ?        Ss   09:07   0:00 avahi-daemon: running [fhem.local]
fhem      1151  3.2  7.9  80436 75640 pts/0    S    11:09   0:23 perl fhem.pl fhem.cfg
pi        1346  0.0  0.2   4296  1912 pts/0    S+   11:20   0:00 grep --color=auto fhem
pi@fhem:~ $ service fhem stop
Failed to stop fhem.service: Access denied
pi@fhem:~ $ sudo service fhem stop
pi@fhem:~ $ sudo service fhem start
pi@fhem:~ $ ps aux | grep fhem
avahi      470  0.0  0.2   3872  2500 ?        Ss   09:07   0:00 avahi-daemon: running [fhem.local]
fhem      1151  2.6  7.9  80436 75640 pts/0    S    11:09   0:23 perl fhem.pl fhem.cfg
pi        1435  0.0  0.2   4296  2016 pts/0    S+   11:23   0:00 grep --color=auto fhem
pi@fhem:~ $

Es kommt zwar die Meldung Starting Fhem...
doch erreichbar ist es erst wieder nach einem Neustart des Pi.
Vielleicht liegt es ja gar nicht an Fhem, sondern am Webserver! Wie kann ich dessen Status überprüfen?

[Hi2Helmi]

Wenn Fhem wieder läuft siehts so aus:

Code Auswählen Erweitern

pi@fhem:~ $ ps aux | grep fhem
avahi      468  0.0  0.2   3872  2560 ?        Ss   11:34   0:00 avahi-daemon: running [fhem.local]
fhem      1007 11.8  7.7  78388 73464 ?        S    11:35   0:13 perl fhem.pl fhem.cfg
pi        1054  0.0  0.2   4296  2012 pts/0    S+   11:37   0:00 grep --color=auto fhem

Ich habe die Weboberfläche noch nicht gestartet.

[persching]

Ich sehe gerade, dass du auch keine configDB verwendest... Ich denke dann sind das vielleicht doch verschiedene Probleme. Ist die einzige Gemeinsamkeit, dass FHEM seit ein paar Tagen abstürzt.

[Hi2Helmi]

Nein verwende ich nicht. Wollte aber schon mal umsteigen. Steht auf meiner ToDo.

[betateilchen]

Mit configDB selbst hat das ursächlich nichts zu tun.

Wenn Du als configDB-Nutzer eine FHEM Seite aufrufst, auf der sich ein Plot befindet, wird das zugehörige gplot File aus der Datenbank gelesen. Dieses Lesen schlägt fehl, weil irgendein Prozess die Datenbank sperrt. Mit "fuser <pfadZurDatenbankdatei>" kannst Du herausfinden, welcher Prozess das ist.

Eine andere Ursache könnte sein, dass Deine Datenbank in sich korrupt ist.

Vielleicht liegt es ja gar nicht an Fhem, sondern am Webserver! Wie kann ich dessen Status überprüfen?

FHEM ist der Webserver.

[betateilchen]

Das einzigste was ich gemacht habe, ich habe ein Fhem-Update eingespielt und den Pi auch upgedatet.

Ich vermute die Ursache für Dein Problem gar nicht in FHEM, sondern in einem Update des Datenbanktreibers im Rahmen Deines pi-Updates.

[persching]

Ich hab jetzt

Code Auswählen Erweitern

fuser /opt/fhem/configDB.db ausgeführt und als Antwort

Code Auswählen Erweitern

/opt/fhem/configDB.db: 22785 erhalten. Ehrlich gesagt bin ich jetzt aber in Sachen Linux nicht so fit dass ich daraus eine sinnvolle Schlussfolgerung ziehen könnte...