Fhem stürzt regelmäßig ab.

Begonnen von Hi2Helmi, 24 Dezember 2017, 10:20:42

Vorheriges Thema - Nächstes Thema

betateilchen

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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

persching

#16
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... :(

Hi2Helmi

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.
MfG
Florian

betateilchen

#18
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?
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!


Hi2Helmi

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?
MfG
Florian