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.
und was steht im Logfile zum Zeitpunkt des Absturzes?
Im Moment des Absturzes gab es keine Meldung, doch nach dem Reboot war die erste Meldung:
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:
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
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
attr initialUsbCheck disable 1und vergiß danach ein save config nicht.
Schöne Weihnachten
Otto
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?
Wenn Dir FHEM abstürzt, sind dann auch die Prozesse weg?
Also per ssh:
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"
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
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
service fhem stop und
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:
Zitat2017.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:
Zitatif ($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.
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:
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?
Wenn Fhem wieder läuft siehts so aus:
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.
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.
Nein verwende ich nicht. Wollte aber schon mal umsteigen. Steht auf meiner ToDo.
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.
Zitat von: Hi2Helmi am 25 Dezember 2017, 11:32:11
Vielleicht liegt es ja gar nicht an Fhem, sondern am Webserver! Wie kann ich dessen Status überprüfen?
FHEM
ist der Webserver.
Zitat von: Hi2Helmi am 24 Dezember 2017, 10:20:42
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.
Ich hab jetzt fuser /opt/fhem/configDB.db ausgeführt und als Antwort /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...
22785 ist die pid (Prozess Id) - quasi die Nummer - des Prozesses, der Deine Datenbank blockiert. (Vorausgesetzt, Du hast das gemacht, als Du wieder in der "Problemsituation" warst)
Aber ohne ein paar Linux Grundlagen wird es echt schwer, Dir zu helfen.
Wenn ich das mach wenn ich versuche eine Seite mit gplot aufzurufen und fhem dann abgeschlossen ist, dann kommt keine pid mehr zurück. Also gehe ich davon aus, dass nur fhem ansich auf die Datenbank zugreift.
Edit:
Jetzt nochmal ausgeführt und folgendes erhalten:
Zitat
root@bananapim2plus:~# fuser /opt/fhem/configDB.db
/opt/fhem/configDB.db: 2172 2179 31860
root@bananapim2plus:~# ps xa
PID TTY STAT TIME COMMAND
1 ? Ss 0:33 /sbin/init sunxi_no_mali_mem_reserve
2 ? S 0:00 [kthreadd]
3 ? S 0:55 [ksoftirqd/0]
5 ? S 0:00 [kworker/u:0]
6 ? S 0:06 [migration/0]
7 ? S 0:08 [watchdog/0]
8 ? S 0:04 [migration/1]
9 ? S 0:12 [kworker/1:0]
10 ? S 0:02 [ksoftirqd/1]
11 ? S 0:08 [watchdog/1]
12 ? S 0:05 [migration/2]
13 ? S 0:00 [kworker/2:0]
14 ? S 0:05 [ksoftirqd/2]
15 ? S 0:06 [watchdog/2]
16 ? S 0:06 [migration/3]
17 ? S 0:00 [kworker/3:0]
18 ? S 0:01 [ksoftirqd/3]
19 ? S 0:07 [watchdog/3]
20 ? S< 0:00 [cpuset]
21 ? S< 0:00 [khelper]
22 ? S 0:00 [kdevtmpfs]
23 ? S< 0:00 [netns]
25 ? S 0:48 [kworker/1:1]
26 ? S 4:51 [kworker/2:1]
27 ? S 0:57 [kworker/3:1]
28 ? S 0:04 [sync_supers]
29 ? S 0:00 [bdi-default]
30 ? S< 0:00 [kintegrityd]
31 ? S< 0:00 [crypto]
32 ? S< 0:00 [kblockd]
33 ? S 0:00 [sytem]
34 ? S 0:00 [khubd]
35 ? S< 0:00 [cfg80211]
36 ? S< 0:00 [rpciod]
37 ? S 0:00 [khungtaskd]
38 ? S 0:35 [kswapd0]
39 ? S< 0:00 [vmstat]
40 ? S 0:00 [fsnotify_mark]
41 ? S< 0:00 [nfsiod]
42 ? S< 0:00 [cifsiod]
57 ? S< 0:00 [SunxiDisCommit]
58 ? S 0:00 [kapmd]
59 ? S< 0:00 [spi.0]
67 ? S 13:15 [cfinteractive]
70 ? S 0:00 [kworker/u:4]
71 ? S 20:58 [mmcqd/2]
72 ? S 0:00 [mmcqd/2boot0]
73 ? S 0:00 [mmcqd/2boot1]
74 ? S 1:46 [hdmi proc]
75 ? S< 0:00 [deferwq]
76 ? S< 0:00 [thermal_wq]
77 ? S< 0:00 [devfreq_wq]
78 ? S 25:08 [kworker/0:2]
132 ? S 0:14 [jbd2/mmcblk0p1-]
133 ? S< 0:00 [ext4-dio-unwrit]
182 ? Ss 42:17 /lib/systemd/systemd-journald
186 ? S 0:00 [kauditd]
193 ? Ss 0:01 /lib/systemd/systemd-udevd
285 ? S 0:00 [wl_event_handle]
286 ? S 0:00 [dhd_watchdog_th]
287 ? S 0:00 [dhd_dpc]
288 ? S 0:00 [dhd_rxf]
364 ? S 0:44 [flush-179:0]
401 ? Ss 0:01 /usr/bin/dbus-daemon --system --address=systemd: --nofor 402 ? Ss 0:00 /usr/bin/irexec /etc/lirc/irexec.lircrc
403 ? Ssl 9:09 /usr/sbin/rsyslogd -n
408 ? Ss 0:00 /usr/sbin/lircmd --nodaemon
409 ? Ss 0:13 /usr/sbin/cron -f
410 ? Ss 0:01 /lib/systemd/systemd-logind
463 ? Ss 3:36 /usr/sbin/lircd --nodaemon
464 ? Ss 0:00 /usr/sbin/lircd-uinput
509 ? Ss 0:00 /usr/sbin/sshd -D
512 ? Ss 0:58 /usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf
521 ? Ss 0:00 /usr/bin/php-cgi
523 ? S 1:37 /usr/sbin/dnsmasq -x /run/dnsmasq/dnsmasq.pid -u dnsmasq 529 ? S 0:02 /usr/bin/php-cgi
530 ? S 0:01 /usr/bin/php-cgi
531 ? S 0:01 /usr/bin/php-cgi
532 ? S 0:01 /usr/bin/php-cgi
748 ? Ss 0:06 /usr/lib/postfix/sbin/master -w
750 ? S 0:01 qmgr -l -t unix -u
764 ? SN 17:40 /bin/bash /usr/local/sbin/rpimonitor-helper.sh /var/run/ 801 ? Ss 0:00 /lib/systemd/systemd --user
834 ? S 0:00 (sd-pam)
856 ? Ss 0:14 /sbin/dhcpcd
859 ttyS0 Ss+ 0:00 /sbin/agetty -L 115200 ttyS0 linux
860 tty1 Ss+ 0:00 /sbin/agetty --noclear tty1 linux
862 ? SNs 0:00 /usr/bin/perl /usr/bin/rpimonitord -b /var/run/rpimonito 872 ? SN 0:00 /usr/bin/perl /usr/bin/rpimonitord -b /var/run/rpimonito 873 ? SN 55:19 /usr/bin/perl /usr/bin/rpimonitord -b /var/run/rpimonito 880 ? Sl 11:34 /usr/bin/pihole-FTL
1193 ? S 0:00 [kworker/0:0]
1231 ? S 0:00 pickup -l -t unix -u -c
1714 ? Rs 0:00 sshd: root@pts/0
1716 ? Ss 0:00 /lib/systemd/systemd --user
1717 ? S 0:00 (sd-pam)
1792 pts/0 Ss 0:00 -bash
2204 ? SN 0:00 sleep 7.5
2209 pts/0 R+ 0:00 ps xa
31860 ? S 1:23 perl fhem.pl configDB
root@bananapim2plus:~#
Edit 2:
Es bleibt dabei, immer wenn ich eine Seite mit gplot aufrufe steht dann dieser Eintrag im Log:
Zitat2017.12.26 12:58:32 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.
2017.12.26 12:58:32 1: PERL WARNING: Issuing rollback() due to DESTROY without explicit disconnect() of DBD::SQLite::db handle dbname=/opt/fhem/configDB.db at configDB.pm line 407.
Und danach ist fhem immer down. Ich hab heute viel probiert, hab die Datenbank bereinigt, hab sie auf konsistenz geprüft, alles in Ordnung, aber hier passiert irgendwas, das fhem killt... :(
Hi,
ich habe Weihnachten gut überstanden und kann mich jetzt wieder meinem Fhem widmen. Heute früh habe ich ein Update von Fhem eingespielt und hatte schon Hoffnung, die Oberfläche war ca. 15 Minuten wie früher erreichbar und benutzbar. Doch dann ist mir Fhem wieder abgeschmiert. Der Datenbankfehler von oben ist nicht mehr da.
Ich habe dann über SSH nochmal folgenden Befehl ausgeführt und diesmal ist fhem 2 mal aufgetaucht. Ist das Normal?
pi@fhem:~ $ ps aux | grep fhem
avahi 470 0.0 0.2 3872 2500 ? Ss Dez26 0:00 avahi-daemon: running [fhem.local]
fhem 6443 3.9 8.0 80336 75704 ? S 08:09 0:22 /usr/bin/perl fhem.pl fhem.cfg
fhem 6471 0.0 7.4 80336 70324 ? S 08:14 0:00 /usr/bin/perl fhem.pl fhem.cfg
pi 6518 0.0 0.1 4296 1820 pts/0 S+ 08:19 0:00 grep --color=auto fhem
Bin so langsam am verzweifeln, da ich keinen Ansatz habe, woran es liegen könnte!!!
P.S.
Gestern habe ich die Oberfläche nicht aufgerufen und Fhem ist stabil durchgelaufen. Es muß also irgendwas mit der Oberfläche zu tun haben. Fhem verabschiedet sich sogar wenn ich nur die Logseite auf dem Bildschirm habe.
es macht wenig Sinn, in einem einzigen Thread mehrere unabhängige Probleme verschiedener Anwender lösen zu wollen.
Kann bitte derjenige, der als letzter mit einem Problem hier auftauchte, einen eigenen Thread aufmachen? Danke.
@Hi2Helmi: dass fhem zweimal in der Prozessliste auftaucht, ist nicht grundsätzlich ein Problem
@persching: Nochmal: Dein Problem kommt nicht von der Datenbank selbst. Setze in Deiner FHEMWEB Instanz das Attribut plotfork auf 0 und teste nochmal. Und was ist das für ein "sleep" in Deiner Prozessliste?
Mein Thema geht hier weiter -> https://forum.fhem.de/index.php/topic,81655.0.html (https://forum.fhem.de/index.php/topic,81655.0.html)
Hallo,
ich habe anscheinend mein Problem gefunden.
Habe immer gedacht es liegt vielleicht an meiner Datenbank und habe diesbezüglich immer in diese Richtung gesucht und nichts gefunden.
Dann ist mir eingefallen, dass ich kurz vor dem Erscheinen des Problems ein readingsHistory erstellt habe und damit Fhem immer wieder zum Absturz gebracht habe.
Habe das readingsHistory wieder gelöscht und seit dem läuft Fhem wieder.
Ist mit diesem Modul ein Fehler diesbezüglich bekannt?