Ich hatte seit gestern das Problem, dass fhem nicht mehr reagierte. Befehle aller Art dauerten bis zur Ausführung mehrere Minuten. WEB-Oberfläche gar nicht mehr erreichbar.
Ich habe nach Fehlerursachen geforscht.
Andere Karte, anderes Netzteil, Deaktivierung einige Module und Entfernung von Hardware.
Ich bin dann dahintergekommen, dass es die Logdatei sein muss, weil der Fehler gefühlt immer erst auftrat, nachdem ich etwas im Log nachgesehen hatte, allerdings leider nicht sofort.
Ich habe dann die Logdatei geleert, weil sie schon gross geworden war wegen verbose 5 und siehe da, der Fehler ist weg.
Ich suche also keine Hilfe, möchte eher die Fehlerursache bekannt machen, falls wieder einmal jemand Probleme dieser Art hat.
Eigentlich kann ich mir das Ganze gar nicht vorstellen, geschweige denn, erklären. Ich habe zur Vorsicht mal das Log aufgehoben.
Wenn ich die Beschreibung richtig verstanden habe, ist FHEM nicht abgestuerzt, sondern war "nur" eine Weile nicht erreichbar.
Womoeglich hat das Betriebsystem Schwierigkeiten beim Zugriff auf die "Platte", entweder weil sie langsam ist, langsam geworden ist, oder defekte Bloecke hat.
Alternativ: je nach IO-Scheduler kann bei Plattenlast eine Filesystem-Operation laenger blockiert sein.
"Abgestürzt" war doch nur die Überschrift.
Ich habe doch geschrieben, dass ich die Karte kopiert habe. Eine Platte habe ich nicht dran und auch nicht erwähnt.
Ich habe dazu ein Image von der Karte auf eine andere Karte kopiert.
Eine Plattenlast kann bei mir eigentlich sowieso nicht entstehen.
Alle 10 bis 15 Minuten ein Schaltvorgang und dazwischen gar nichts. Auch kein Logeintrag oder sonstige Reaktion.
Ich kann den Fehler reproduzieren. Wenn ich die alte Logdatei wieder reinkopiere, blockiert fhem erneut. Defekte Karte scheidet also aus.
Es sollte nur ein Tipp sein, für die Leute, die auch irgendwann einmal eine Fehlerquelle ausschliessen müssen.
Hab die Überschrift angepasst.
Zitat"Abgestürzt" war doch nur die Überschrift.
Mag sein, ich wollte das fuer andere Leser, die aehnliche Probleme haben, klarstellen.
ZitatIch habe dann die Logdatei geleert, weil sie schon gross geworden war wegen verbose 5 und siehe da, der Fehler ist weg.
...
Eine Plattenlast kann bei mir eigentlich sowieso nicht entstehen.
Diese beiden Aussagen sind mAn widerspruechlich.
Mit "Platte" meinte ich etwas, was zum dauerhaften speichern der Daten geeignet ist, und die erwaehnten Probleme koennen alle haben.
Mit anderen Effekten kann ich das Problem nicht erklaeren, lerne aber gerne dazu.
Die Logdatei war anfangs nicht sehr gross, aber durch meine Tests, Neustarts und verbose 5 wuchs sie dann an und wurde für mich unübersichtlich. Es sind rund 2,5 MB.
Vor verbose 5 waren es rund 4000 Zeilen, später dann mit verbose 5 waren es 34000 Zeilen. Aber als der Fehler erstmalig auftrat, waren es um die 1000 Zeilen.
Für mich ist die ganze Sache noch viel unerklärlicher. Deshalb hat ja auch die Fehlersuche sehr lange gedauert, da ich die Datei natürlich gar nicht verdächtigt hatte. Ist halt völlig irre.
Ich hätte das auch garnicht hier geschrieben, aber ich hoffe halt, dass irgendwann doch jemand davon profitiert. Immerhin kann ja ein Test nicht schaden.
ZitatEs sind rund 2,5 MB
Das ist meines Erachtens klein. Ich hatte schon das 10-fache.
Dein Problem muss irgendwo anders liegen. Ich würd auf OS-Ebene tippen oder etwas, was in Abhängigkeit der Größe archivieren soll. :-\
Ich selber habe keinerlei Archivierung veranlasst. Ich mache das immer manuell per Imagebackup unter Windows.
Die Logdatei wird ja jeden Monat neu erzeugt und machte noch nie Probleme. Ich habe sie ja auch nicht weggeworfen. Der Alias zur Löschung lautet bei mir:
dellog AS {qx(truncate $currlogfile --size 0);Log 1, "Logfile gelöscht";}
Ich weiss nicht, ob die Datei damit gelöscht, oder nur geleert wird.
Der Inhalt der Logdatei wird ja vermutlich unter fhem nicht ausgewertet. Ein Zugriff auf die Log war im Fehlerfall nicht notwendig, daher vermute ich, dass der Zugriff (das Schreiben ins Log durch fhem) genügt hat.
Wenn ich die Datei aufgerufen habe, lief fhem noch kurze Zeit anstandslos, dann wurde aber blockiert. Da das Verhalten nicht regelmäßig auftrat, also z.B. 10 Sekunden nach dem Öffnen, war ein Zusammenhang nicht sofort erkennbar. Zu dem Zeitpunkt des Fehlers hatte ich auch (wie Andere) Probleme mit dem Echo-Modul - npm-Login. Wenn das nicht klappte, blockierte fhem auch sofort. Ich dachte, Echo hat Schuld, aber es wurde vermutlich hier nur durch den Fehler ein Logeintrag erzeugt, der dann den Fehler hervorrief.
Alles sehr kompliziert und daher nicht richtig gut einzugrenzen.
Sei es, wie es sei - es ist und bleibt erst einmal merkwürdig.
hast du z.B.
attr <web> reverseLogs 1
das wäre ein Killer bei großen Files
Nein, habe ich nicht. Es lief ja auch bisher alles klaglos. Das System habe ich ja erst letzten Monat neu aufgesetzt. Lief und läuft wie geölt. Nicht einmal der HM-Lan macht Probleme. Raspi hängt am Kabel direkt am Router. Ich habe nicht einmal Perl-Warnungen. Auch Freezemon zeigt nur die "normalen" Unregelmäßigkeiten.
Ich hatte auch das Logfile wieder zurückgespielt und der Fehler war wieder da. Logfile geleert und der Fehler ist weg. Und, wie gesagt, 1,5 MB ist auch nicht der Blocker.
Wenn ich Lust haben sollte, teile ich die Datei mal so lange auf, bis die Fehlerstelle eingegrenzt ist. Ich weiss nur nicht, ob das überhaupt möglich ist, sollte aber gehen, ohne Probleme zu machen.
Wenn das Wetter schlechter wird, ziehe ich das vielleicht mal durch.
ZitatWenn ich Lust haben sollte, teile ich die Datei mal so lange auf, bis die Fehlerstelle eingegrenzt ist.
"Fehlerstelle" wird es keine geben. Du schriebst ja selber schon, dass die Log-Datei keinerlei Auswertungen unterliegt. Es ist eine "dumme" Datei, die halt immer weiter um zusätzliche Daten erweitert wird. Ich kann mich daher nur Rudis ersten Gedanken anschließen.
Nimm doch mal bei "stehendem" FHEM per Editor einige Zeilen aus der Datei. Dann Start von FHEM. Mit verbose5 sollte Sie dann relativ flott wieder "überlaufen"(oder FHEM erst gar nicht starten ? :-\). Das Ganze über putty mit top/ps aux beobachten. Oder es dauert und sie wird nun viel größer. Das wäre ja ein Indiz, dass irgendwelche "Puffer" voll laufen..., also ein OS-nahes Problem.
Danke. Werde ich gelegentlich in Angriff nehmen, denke ich.
Hallo Invers,
ich hatte dieses Verhalten heute Nachmittag auch!
Habe bei einem echodevice (37_echodevice.pm) mal verbose 5 eingestellt und das Logfile auf 7,6 MByte aufgebläht.
Danach hat fhem nicht mehr reagiert, es lief aber noch. Also fhem gestoppt, das Logfile gelöscht und verbose 5 aus dem echodevice rausgelöscht. fhem wieder gestartet und schwupps: Alles wieder gut ::) ???
fhem läuft bei mir in einem LXC auf nem Proxmox Host (SSD).
VG Sebastian
Auf meinen Testsystemen hab ich das auch schon beobachtet...
Testsysteme, weil da halt viel getestet wird... ;)
...und da schon mal mehr geloggt wird...
Plattformen: PI3 mit SD...
Könnte jetzt nicht sagen ab welcher Größe aber bei 1, 2, 3MB wird es soweit sein...
Dass fhem generell nicht mehr reagiert hatte ich (glaub ich noch nicht), träge wohl schon...
...außer ich versuche das fhem-Log per Web anzuzeigen...
Dann ist's/war's "vorbei"...
Auf meinem Hauptsystem bin ich immer deutlich untet 1MB (außer es läuft mal was gewaltig schief aber dann is auch schon egal ;) ) und da gibt es keine Probleme...
Auf dem Testsystem wird halt einfach gestoppt, Log wegverschoben (wegen Analyse) und dann wieder gestartet...
Gruß, Joachim
ich hatte schon logfiles mit mehreren 100mb. das ist völlig problemlos.
wie rudi schon gesagt hat: ich bin mir ziemlich sicher dass kein fhem problem ist. das logfile wird nur geschrieben. d.h. zeilen hinten angehängt.
vielleicht mal mit top/iotop und strace an fhem schauen was genau passiert.
Im normal laufenden System habe ich folgende Anzeige, die ich allerdings nicht deuten kann:
top - 20:03:29 up 1 day, 51 min, 2 users, load average: 0,05, 0,06, 0,04
Tasks: 130 total, 1 running, 78 sleeping, 0 stopped, 1 zombie
%Cpu(s): 0,8 us, 0,3 sy, 0,0 ni, 98,8 id, 0,0 wa, 0,0 hi, 0,1 si, 0,0 st
KiB Mem : 948304 total, 306404 free, 252196 used, 389704 buff/cache
KiB Swap: 102396 total, 102396 free, 0 used. 629316 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
24215 fhem 20 0 112928 106908 8732 S 2,6 11,3 30:36.80 perl
13357 pi 20 0 8512 3348 2856 R 1,0 0,4 0:01.27 top
697 pi 20 0 137284 28980 20104 S 0,3 3,1 3:36.27 lxpanel
1 root 20 0 27084 6076 4880 S 0,0 0,6 0:05.67 systemd
2 root 20 0 0 0 0 S 0,0 0,0 0:00.14 kthreadd
3 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 rcu_gp
4 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 rcu_par_gp
8 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 mm_percpu_wq
9 root 20 0 0 0 0 S 0,0 0,0 0:04.90 ksoftirqd/0
10 root 20 0 0 0 0 I 0,0 0,0 0:26.59 rcu_sched
11 root 20 0 0 0 0 I 0,0 0,0 0:00.00 rcu_bh
12 root rt 0 0 0 0 S 0,0 0,0 0:00.03 migration/0
13 root 20 0 0 0 0 S 0,0 0,0 0:00.00 cpuhp/0
14 root 20 0 0 0 0 S 0,0 0,0 0:00.00 cpuhp/1
15 root rt 0 0 0 0 S 0,0 0,0 0:00.02 migration/1
16 root 20 0 0 0 0 S 0,0 0,0 0:02.40 ksoftirqd/1
19 root 20 0 0 0 0 S 0,0 0,0 0:00.00 cpuhp/2
Für iotop bin ich zu doof, da kommt bei Eingabe:
-bash: iotop: Kommando nicht gefunden.
bei
strace -p 24215
kommt dann:
strace: attach: ptrace(PTRACE_SEIZE, 24215): Operation not permitted
pi@fhem3:~ $ strace -p 24215
strace: attach: ptrace(PTRACE_SEIZE, 24215): Operation not permitted
Damit kann ich also offenbar auch noch nicht umgehen.
Ich werde also versuchen, mich zu bilden und dann das zu grosse oder defekte Log noch einmal einspielen und testen.
Danke.
sudo bei strace.
iotop vermutlich nicht installiert.
;)
Danke dir. Hab ich nachinstalliert.
Jetzt kann ich mal kontrollieren, wenn der Fehler wieder auftritt.
Der Fehler tritt nun mit der aktuellen Logdatei erneut auf, wenn man die Logdatei lesen will.
Diese wird noch angezeigt, dann wird aber blockiert.
Öffnet man die Log nicht, kommt auch kein Fehler. Schreiben scheint also zu funktionieren.
Ich habe mal hier eine kurze Zusammenstellung, was ich so sehen konnte, bevor fhem von selbst wieder weiterlief.
Leider nicht in Codetags, man möge versuchen, mir zu verzeihen.
iotop hin und wieder 10 - 30 kb
top - 11:28:50 up 4 days, 16:16, 2 users, load average: 0,10, 0,06, 0,02
Tasks: 127 total, 1 running, 80 sleeping, 0 stopped, 1 zombie
%Cpu(s): 0,3 us, 0,1 sy, 0,0 ni, 99,7 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
KiB Mem : 948304 total, 179656 free, 278284 used, 490364 buff/cache
KiB Swap: 102396 total, 102396 free, 0 used. 596748 avail Mem
fhem.service loaded active running FHEM Home Automation
ps xa ergibt
9442 ? S 8:15 /usr/bin/perl fhem.pl configDB
9465 ? Sl 0:14 node /usr/local/bin/alexa-fhem -c ./alexa-fhem.cfg
9471 ? S 0:00 /usr/bin/perl fhem.pl configDB
9547 ? S 0:00 /usr/bin/ssh -R 1234:127.0.0.1:34537 -oServerAliveInterval=90 -i /opt/fhem/.ssh/id_rsa -p 588
sudo strace
strace: Process 9442 attached
_newselect(72, NULL, [71], NULL, NULL
strace: Process 9442 attached
_newselect(72, NULL, [71], NULL, NULL
strace: Process 9465 attached
epoll_wait(3,
Dann Stillstand und nach langer einigen Sekunden
folgende Ausgabe (scheinbar in dem Moment, wo fhem dann weiterlief:
#[{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"myFreezemon\",\"s:11:23:17 e:11:"..., 65536) = 65483
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "\"Webradio-elapsed\",\"1445.436\",\"1"..., 65536) = 15128
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"Heizung_Wz\",\"measured-temp: 28"..., 65536) = 65536
futex(0x128e2b4, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x128e2b0, FUTEX_OP_SET<<28|0<<12|FUTEX_OP_CMP_GT<<24|0x1) = 1
futex(0x128e298, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x12b4e58, FUTEX_WAKE_PRIVATE, 1) = 1
write(1, " 2019-06-30 11:39:20 caching: S"..., 58) = 58
write(1, "[30.6.2019, 11:39:20] [FHEM] "..., 76) = 76
read(10, "\"2\",\"2\"]\n[\"DI_Batterie_Thermomet"..., 65536) = 6938
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"MQTT2_Server\",\"Initialized\",\"<"..., 65536) = 46943
mmap2(0x46200000, 524288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x46200000
mmap2(0x5d180000, 524288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x5d180000
write(8, "\1\0\0\0\0\0\0\0", 8) = 8
getpid() = 9465
epoll_wait(3, [{EPOLLIN, {u32=8, u64=8}}], 1024, -1) = 1
read(8, "\1\0\0\0\0\0\0\0", 1024) = 8
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"Heizung_Wz\",\"measured-temp: 28"..., 65536) = 65536
write(1, " 2019-06-30 11:39:26 caching: H"..., 62) = 62
write(1, "[30.6.2019, 11:39:26] [FHEM] "..., 92) = 92
read(10, "23\",\"2019-06-30 11:39:23\"]\n[\"DI_"..., 65536) = 65536
futex(0x128e2b4, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x128e2b0, FUTEX_OP_SET<<28|0<<12|FUTEX_OP_CMP_GT<<24|0x1) = 1
futex(0x128e298, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x12b4e58, FUTEX_WAKE_PRIVATE, 1) = 1
write(1, " 2019-06-30 11:39:26 caching: S"..., 60) = 60
write(1, "[30.6.2019, 11:39:26] [FHEM] "..., 96) = 96
write(1, " 2019-06-30 11:39:26 caching: P"..., 61) = 61
write(1, "[30.6.2019, 11:39:26] [FHEM] "..., 96) = 96
read(10, "15 -1 -25 8 -9 40 -13 108 -13 10"..., 65536) = 65536
mmap2(0x32600000, 524288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x32600000
mmap2(0x28800000, 524288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x28800000
write(8, "\1\0\0\0\0\0\0\0", 8) = 8
getpid() = 9465
write(1, " 2019-06-30 11:39:26 caching: T"..., 59) = 59
write(1, "[30.6.2019, 11:39:26] [FHEM] "..., 96) = 96
write(1, " 2019-06-30 11:39:26 caching: P"..., 53) = 53
write(1, "[30.6.2019, 11:39:26] [FHEM] "..., 107) = 107
write(1, " 2019-06-30 11:39:26 caching: P"..., 49) = 49
write(1, "[30.6.2019, 11:39:26] [FHEM] "..., 90) = 90
write(1, " 2019-06-30 11:39:26 caching: P"..., 53) = 53
write(1, "[30.6.2019, 11:39:26] [FHEM] "..., 96) = 96
write(1, " 2019-06-30 11:39:26 caching: U"..., 52) = 52
write(1, "[30.6.2019, 11:39:26] [FHEM] "..., 93) = 93
write(1, " 2019-06-30 11:39:26 caching: U"..., 54) = 54
write(1, "[30.6.2019, 11:39:26] [FHEM] "..., 96) = 96
read(10, "0 -23 125 -147 139 -138 21 13 11"..., 65536) = 2145
epoll_wait(3, [{EPOLLIN, {u32=8, u64=8}}], 1024, -1) = 1
read(8, "\1\0\0\0\0\0\0\0", 1024) = 8
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"Kuechenradio\",\"off\",\"<div id=\\"..., 65536) = 65483
futex(0x128e2b4, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x128e2b0, FUTEX_OP_SET<<28|0<<12|FUTEX_OP_CMP_GT<<24|0x1) = 1
futex(0x128e298, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x12b4e58, FUTEX_WAKE_PRIVATE, 1) = 1
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "xmlns:cc=\\u0022http://creativeco"..., 65536) = 15795
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"myFreezemon\",\"s:11:39:27 e:11:"..., 65536) = 53177
mmap2(0x5d180000, 524288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x5d180000
mmap2(0x46200000, 524288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x46200000
write(8, "\1\0\0\0\0\0\0\0", 8) = 8
getpid() = 9465
epoll_wait(3, [{EPOLLIN, {u32=8, u64=8}}], 1024, -1) = 1
read(8, "\1\0\0\0\0\0\0\0", 1024) = 8
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"TMP_Ku\",\"T: 27.9 H: 48.0\",\"<di"..., 65536) = 26024
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"XiaomiGateway\",\"Connected\",\"<d"..., 65536) = 7488
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"MQTT2_Server\",\"Initialized\",\"<"..., 65536) = 10165
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"MyTTS\",\"Initialized\",\"<div id="..., 65536) = 7458
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"Webradio\",\"play\",\"<table><tr><"..., 65536) = 7894
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"MQTT2_Server\",\"Initialized\",\"<"..., 65536) = 15039
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"XiaomiGateway\",\"Connected\",\"<d"..., 65536) = 13671
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"MQTT2_Server\",\"Initialized\",\"<"..., 65536) = 30938
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"MQTT2_Server\",\"Initialized\",\"<"..., 65536) = 10994
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"MQTT2_Server\",\"Initialized\",\"<"..., 65536) = 7895
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"MQTT2_Server\",\"Initialized\",\"<"..., 65536) = 14192
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"MQTT2_Server\",\"Initialized\",\"<"..., 65536) = 7551
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"MQTT2_Server\",\"Initialized\",\"<"..., 65536) = 7488
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"MQTT2_Server\",\"Initialized\",\"<"..., 65536) = 29757
futex(0x128e2b4, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x128e2b0, FUTEX_OP_SET<<28|0<<12|FUTEX_OP_CMP_GT<<24|0x1) = 1
futex(0x128e298, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x12b4e58, FUTEX_WAKE_PRIVATE, 1) = 1
mmap2(0x28800000, 524288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x28800000
mmap2(0x32600000, 524288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x32600000
write(8, "\1\0\0\0\0\0\0\0", 8) = 8
getpid() = 9465
epoll_wait(3, [{EPOLLIN, {u32=8, u64=8}}], 1024, -1) = 1
read(8, "\1\0\0\0\0\0\0\0", 1024) = 8
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"MQTT2_Server\",\"Initialized\",\"<"..., 65536) = 7385
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"MQTT2_Server\",\"Initialized\",\"<"..., 65536) = 11533
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"MQTT2_Server\",\"Initialized\",\"<"..., 65536) = 3550
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"XiaomiGateway\",\"Connected\",\"<d"..., 65536) = 7386
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"Webradio\",\"play\",\"<table><tr><"..., 65536) = 10382
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"MQTT2_Server\",\"Initialized\",\"<"..., 65536) = 14980
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"XiaomiGateway\",\"Connected\",\"<d"..., 65536) = 7488
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"MQTT2_Server\",\"Initialized\",\"<"..., 65536) = 13715
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"Webradio\",\"play\",\"<table><tr><"..., 65536) = 19883
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"MQTT2_Server\",\"Initialized\",\"<"..., 65536) = 3550
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"XiaomiGateway\",\"Connected\",\"<d"..., 65536) = 11038
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"XiaomiGateway\",\"Connected\",\"<d"..., 65536) = 24136
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"Steckdose_2\",\"off\",\"<div id=\\u"..., 65536) = 21209
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"XiaomiGateway\",\"Connected\",\"<d"..., 65536) = 22550
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"XiaomiGateway\",\"Connected\",\"<d"..., 65536) = 6518
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"XiaomiGateway\",\"Connected\",\"<d"..., 65536) = 6606
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"XiaomiGateway\",\"Connected\",\"<d"..., 65536) = 10615
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"XiaomiGateway\",\"Connected\",\"<d"..., 65536) = 6562
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"XiaomiGateway\",\"Connected\",\"<d"..., 65536) = 17806
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"XiaomiGateway\",\"Connected\",\"<d"..., 65536) = 6562
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"XiaomiGateway\",\"Connected\",\"<d"..., 65536) = 21944
mmap2(0x46200000, 524288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x46200000
mmap2(0x5d180000, 524288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x5d180000
write(8, "\1\0\0\0\0\0\0\0", 8) = 8
getpid() = 9465
epoll_wait(3, [{EPOLLIN, {u32=8, u64=8}}], 1024, -1) = 1
read(8, "\1\0\0\0\0\0\0\0", 1024) = 8
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"XiaomiGateway\",\"Connected\",\"<d"..., 65536) = 6606
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"XiaomiGateway\",\"Connected\",\"<d"..., 65536) = 6518
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"XiaomiGateway\",\"Connected\",\"<d"..., 65536) = 22014
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"XiaomiGateway\",\"Connected\",\"<d"..., 65536) = 6606
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"XiaomiGateway\",\"Connected\",\"<d"..., 65536) = 10659
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"XiaomiGateway\",\"Connected\",\"<d"..., 65536) = 6606
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"XiaomiGateway\",\"Connected\",\"<d"..., 65536) = 17808
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"XiaomiGateway\",\"Connected\",\"<d"..., 65536) = 6606
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"XiaomiGateway\",\"Connected\",\"<d"..., 65536) = 10659
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"XiaomiGateway\",\"Connected\",\"<d"..., 65536) = 6606
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"XiaomiGateway\",\"Connected\",\"<d"..., 65536) = 6606
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"XiaomiGateway\",\"Connected\",\"<d"..., 65536) = 6606
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"XiaomiGateway\",\"Connected\",\"<d"..., 65536) = 6606
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"Fritzbox\",\"WLAN: on gWLAN: off"..., 65536) = 20439
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"XiaomiGateway\",\"Connected\",\"<d"..., 65536) = 6606
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"XiaomiGateway\",\"Connected\",\"<d"..., 65536) = 6606
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"XiaomiGateway\",\"Connected\",\"<d"..., 65536) = 6606
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"XiaomiGateway\",\"Connected\",\"<d"..., 65536) = 6562
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"XiaomiGateway\",\"Connected\",\"<d"..., 65536) = 6562
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"XiaomiGateway\",\"Connected\",\"<d"..., 65536) = 6562
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"XiaomiGateway\",\"Connected\",\"<d"..., 65536) = 6562
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"TMP_Sz\",\"error\",\"<div id=\\u002"..., 65536) = 7199
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"XiaomiGateway\",\"Connected\",\"<d"..., 65536) = 6606
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"XiaomiGateway\",\"Connected\",\"<d"..., 65536) = 6606
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"XiaomiGateway\",\"Connected\",\"<d"..., 65536) = 6606
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"XiaomiGateway\",\"Connected\",\"<d"..., 65536) = 6606
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"XiaomiGateway\",\"Connected\",\"<d"..., 65536) = 6606
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"XiaomiGateway\",\"Connected\",\"<d"..., 65536) = 6606
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"XiaomiGateway\",\"Connected\",\"<d"..., 65536) = 6606
mmap2(0x32600000, 524288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x32600000
mmap2(0x28800000, 524288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x28800000
write(8, "\1\0\0\0\0\0\0\0", 8) = 8
getpid() = 9465
epoll_wait(3, [{EPOLLIN, {u32=8, u64=8}}], 1024, -1) = 1
read(8, "\1\0\0\0\0\0\0\0", 1024) = 8
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"XiaomiGateway\",\"Connected\",\"<d"..., 65536) = 6606
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"XiaomiGateway\",\"Connected\",\"<d"..., 65536) = 6606
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"XiaomiGateway\",\"Connected\",\"<d"..., 65536) = 6606
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"XiaomiGateway\",\"Connected\",\"<d"..., 65536) = 6606
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"XiaomiGateway\",\"Connected\",\"<d"..., 65536) = 6606
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"XiaomiGateway\",\"Connected\",\"<d"..., 65536) = 3303
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"Webradio\",\"play\",\"<table><tr><"..., 65536) = 16600
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"Webradio\",\"play\",\"<table><tr><"..., 65536) = 4094
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"XiaomiGateway\",\"Connected\",\"<d"..., 65536) = 3303
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"MQTT2_Server\",\"Initialized\",\"<"..., 65536) = 247
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"Steckdose_3\",\"off\",\"<div id=\\u"..., 65536) = 3689
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"Steckdose_3\",\"off\",\"<div id=\\u"..., 65536) = 19519
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"HMLAN1\",\"opened\",\"<div id=\\u00"..., 65536) = 10626
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"TMP_Wz\",\"T: 28.0 H: 38.0\",\"<di"..., 65536) = 412
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"XiaomiGateway\",\"Connected\",\"<d"..., 65536) = 3303
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"TMP_Ku\",\"T: 28.0 H: 50.0\",\"<di"..., 65536) = 362
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"DI_Batterie_Thermometer\",\"cmd_"..., 65536) = 1014
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"DI_KuechenradioSender\",\"cmd_3\""..., 65536) = 15838
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"XiaomiGateway\",\"Connected\",\"<d"..., 65536) = 3303
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"HMLAN1\",\"opened\",\"<div id=\\u00"..., 65536) = 10626
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"XiaomiGateway\",\"Connected\",\"<d"..., 65536) = 3303
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"DI_KuechenradioSender\",\"cmd_3\""..., 65536) = 15838
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"Webradio\",\"play\",\"<table><tr><"..., 65536) = 16741
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"Webradio\",\"play\",\"<table><tr><"..., 65536) = 4103
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"Webradio\",\"play\",\"<table><tr><"..., 65536) = 4909
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"TMP_Bad\",\"T: 26.7 H: 45.0\",\"<d"..., 65536) = 1390
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"XiaomiGateway\",\"Connected\",\"<d"..., 65536) = 3303
epoll_wait(3, [{EPOLLIN, {u32=10, u64=10}}], 1024, -1) = 1
read(10, "[\"DI_KuechenradioSender\",\"cmd_3\""..., 65536) = 15838
epoll_wait(3, ^Cstrace: Process 9465 detached
<detached ...>
Mehr konnte ich nciht testen, da dann fhem wieder lief.
Zitatwenn man die Logdatei lesen will.
Du meinst mit FHEM-Webinterface ? Das mach ich nie mit der Logdatei, da dafür wirklich zu groß und blockierend. Ich öffne mit Editor, z.B. WinSCP, notepad++....
Ich mache das schon seit vielen Jahren so und hatte bisher noch keine Probleme. Die Log-Dateien waren ja früher auch lang.
Ich möchte das Thema noch einmal ansprechen.
Das Problem ist eindeutig die Grösse der Logdateien. Egal, welche Datei - bei grösser 0,5 MB hängt fhem definitiv für mindestens 9 Minuten fest. In dieser Zeit scheint sich fhem irgendwie alle Aktionen zu merken und führt diese aus, wenn die Blockierung beendet ist.
Ich habe nun den MC auf dem Pi installiert und dem ist die Dateigrösse egal. Bei jeder Dateigrösse läuft fhem verzögerungsfrei weiter, wenn im mc geöffnet wurde.
Die Preisfrage ist also, warum kann fhem keine grossen Dateien anzeigen und der mc schon? Kann das dann trotzdem mit dem Betriebssystem zusammenhängen? Irgendwie normal scheint das ja nicht zu sein, wenn andere Programme alles anzeigen können. Ich möchte das Thema noch einmal ansprechen.
Das Problem ist eindeutig die Grösse der Logdateien. Egal, welche Datei - bei grösser 0,5 MB hängt fhem definitiv für mindestens 9 Minuten fest. In dieser Zeit scheint sich fhem irgendwie alle Aktionen zu merken und führt diese aus, wenn die Blockierung beendet ist.
Ich habe nun den MC auf dem Pi installiert und dem ist die Dateigrösse egal. Bei jeder Dateigrösse läuft fhem verzögerungsfrei weiter.
Die Preisfrage ist also, warum kann fhem keine grossen Dateien anzeigen und der mc schon? Kann das dann trotzdem mit dem Betriebssystem zusammenhängen? Irgendwie normal scheint das ja nicht zu sein, wenn andere Programme alles anzeigen können.
Ich habe gerade eine 8+MB grosse Logdatei in FHEMWEB angezeigt:
- FHEM hat dafuer weniger als 0.5CPU Sekunden gebraucht, der Prozess hat keinen signifikanten Speicher alloziert.
- Chrome war fuer geschaetzt 60+ Sekunden mit Rendern beschaeftigt, solange konnte man nur den ersten Teil der Daten mit weissen Hintergrund sehen
- FHEM war waehrend der "Chrome-Render-Zeit" nicht blockiert, sowohl telnet, wie auch FHEMWEB in einem weiteren Chrome Tab war gewohnt schnell.
=> Dein Problem hat nicht "generell" mit der FHEMWEB Logfile Anzeige zu tun, es muss eine andere Ursache haben.
Bei mir treten auch keinerlei sonstige sichtbare Blockaden im Pi oder am PC auf.
Ich arbeite mit einem Pi 3b+ mit Stretch lite und einem relativ neu aufgesetzten System nebst fhem. Ich habe keine Daten irgendwelcher Art aus dem alten System übernommen, sondern alles neu angelegt oder per defmod. Ich habe 2 Karten mit denen ich abwechselnd arbeite, monatlich eine andere Karte. Die Karten werden jeweils auf die andere Karte kopiert (Image)
Da die Anzeige aller Dateien ausserhalb von fhem auch auf dem Pi direkt funktioniert, sehe ich keine Fehlerquelle. Da der Fehler aber reproduzierbar ist, muss ja eine Ursache da sein. Früher dachte ich, das beträfe nur die Logdatei von fhem, aber es betrifft alle grösseren Dateien.
Hätte ich nicht gerade erst alles neu gemacht, wäre es mir ja auch egal. Aber so ist es halt ungerecht, hinterhältig und gemein vom Verursacher.
Ich werde bis zum Umstieg auf den Pi 4 damit leben. Dann mache ich noch einmal alles neu und gucke, ob es dann läuft.
Es gibt neue Erkenntnisse, die diese Sache noch mysteriöser erscheinen lassen.
Ich habe keinerlei Probleme mit grossen Logs, wenn ich die auf anderen Geräten, also Tab und anderer Win-PC aufrufe. Nur mit meinem Hauptrechner, den ich also ständig nutze, tritt das Problem auf. Windows-Version ist gleich und es lief ja auch früher.
Weiss jemand, ob derselbe Browsercache von allen Browsern genutzt wird? falls ja, könnte ich ja mal alle Browser deinstallieren und die Ordner dazu löschen.
UPDATE zum Problem:
Man kann in Firefox ein privates Fenster öffnen. wenn ich das mache, wird fhem innerhalb dieses Fensters ebenfalls nicht blockiert. Ich kann da lesen, so viel ich will. Das Problem kann aber nicht der Firefox sein, da es ja in allen Browsern passiert.
Die Frage lautet also eigentlich:
Wie schafft es Windows mit einem beliebigen Browser (EDGE, Firefox, Chrome) fhem zu blockieren?
Wenn das jemand herausbekommt, könnte er ja fhem bewusst blockieren. Ich weiss nicht, ob man das schon als Sicherheitsrisiko/Lücke einstufen kann. Vermutlich nicht, da man ja dazu bereits Zugriff auf fhem haben muss.
Und es muesste noch nachgewiesen werden, dass FHEM selbst blockiert wird, und nicht nur der Browser.
Das kann ich nur argumentativ nachweisen.
wenn fhem blockiert wird, dann wird durch fhem nichts mehr geschaltet.
Beispiel:
Ich habe einen HM-Wandtaster. wird dieser von mir betätigt, dann werden mir einige Infos angesagt, die meine Sensoren messen.
Im Fall der Blockade dauert es halt, bis die ungefähr 9 Minuten um sind, dann wird angesagt, weil ich vor 9 Minuten getastet habe.
Ein Zugriff auf die Oberfläche von fhem ist während der Blockade von keinem Gerät und keinem Browser mehr möglich.
Ausgelöst wird die Blockade aber ausschliesslich auf meinem PC mit Win 10, wenn ich halt eine grosse Datei anzeigen lassen will. Es ist dabei egal, um welche Log es sich handelt.
Auf einem 2. PC mit Win 10 passiert nichts dergleichen.
Es muss also theoretisch irgendetwas zum Pi geschickt werden, woran sich fhem verschluckt.
Ich habe keine Idee, wie ich die geschickten Befehlsdaten (also wenn ich auf Log anzeigen klicke) anzeigen kann. Ich könnte ja sonst vergleichen, was fhem von beiden PCs geschickt bekommt.
Besser kann ich es nicht nachweisen, es sei denn, ich bekomme eine Ansage, was ich tun soll.
obwohl es hier "nur" um 9 minuten geht, habe ich das gefühl, dass dieses phänomen vielleicht ähnliche ursachen hat wie bei jenem phänomen:
Zitat von: rudolfkoenig am 19 Juli 2019, 09:57:33
Es fuehrt nicht zum Absturz, FHEM wartet nur 10 Minuten, weil UWZ.pm in Zeile 882 das so bestellt hat:Das 1 steht fuer waitIfInitNotDone, d.h. wenn fhem.cfg noch nicht _komplett_ eingelesen wurde.
Warum das nur beim rereadcfg ein Problem ist, ist mir noch unklar, das kann aber gerne so bleiben :)
Ich habe neue Erkenntnisse:
Es gibt ja den Link "jump to the end" in allen Textdateien.
Die Blockierung trittnur auf, wenn ich diesen Link klicke.
In Android funktioniert der Link jedoch nicht (bei mir). Daher trat dort natürlich auch keine Blockade auf.
Der Fehler sollte also im Zusammenhang mit diesem Link stehen.
Ich wundere mich auch, dass der Link in Windows funktioniert, wenn auch blockierend, aber in Android leider gar nicht.
Kann mir bitte jemand sagen, welches Modul ich zwangsupdaten sollte, damit eventuell alles wieder geht?
Könnte ja sein, dass sich bei mir ein Fehler in diesem Modul (warum auch immer) eingeschlichen hat.
Ich habe einen etwas groesseren Log (500k+) als Textdatei unter Android (Style:f18) angezeigt, und jump to the end/jump to the top getestet: es funktioniert und FHEM ist nicht blockiert => ich kann das Problem nicht nachvollzienen.
Danach Windows aufgetrieben, und da mit IE11 das Gleiche durchgefuehrt => kein sichtbares Problem / keine Blockade
ZitatDie Blockierung trittnur auf, wenn ich diesen Link klicke.
Klingt unplausibel, da beim Klick nicht mit dem FHEM-Server kommuniziert wird, es wird ja nicht mal JavaScript bemueht, das ist triviales HTML:
<a name='top'></a>
<a href='#end_of_file'>jump to the end</a>
...
TEXT
...
<a name='end_of_file'></a>
<a href='#top'>jump to the top</a>
OK, danke. Ich werde als letzten Vesuch mal alles komplett updaten. Vielleicht ist ein Modul kaputt gegangen. Der Fehler muss ja irgendwie bei fhem liegen. Es ist unwahrscheinlich, dass Windows und Android gleichzeitig auf allen Geräten anfangen zu spinnen.
Komplettes Update aller Dateien hat leider nicht geholfen.
Ich habe nun bemerkt, dass der Fehler nur mit f18 auftritt. In allen anderen Styles, die ich probiert habe, funktioniert alles problemlos.
Welche Dateien genau sind denn an f18 beteiligt? Vielleicht hilft es ja, alle beteiligten Dateien per Hand zu auszutauschen.
Wenn die Fehler ausschliesslich in f18 auftreten, müsste sich doch etwas finden lassen.
Momentan nutze ich flex, da ist mir aber die Schrift von Code-Mirror zu klein und meine Bahnhofsuhr läuft nicht. Deshalb würde ich eigentlich lieber f18 nutzen.
So, ich habe nun die Fehlerquelle eindeutig gefunden.
Ich nutze die Bahnhofsuhr unter f18. Wenn ich diese entferne 8durch löschen der Datei pgm2/clock.js im Attribut von WEB, dann funktioniert auch unter f18 alles normal.
Die Uhr musste ich in Flex entfernen, da die Menüdarstellung nicht richtig klappte. Somit hatte ich im Anschluss natürlich auch in den anderen Styles beim Test die Uhr nicht drinnen. Das ist der Grund, weshalb ich den Zusammenhang nicht sofort bemerkt hatte.
Heute habe ich also noch einmal f18 getestet. Da die Uhr ja nicht installiert war wegen Flex, lief plötzlich auch f18. Nach Eintragung der pgm2/clock.js im Attribut wurde sofort wieder blockiert. Das habe ich nun mehrfach ausprobiert. Mit Uhr wird blockiert, ohne Uhr läuft alles.
Der Fall ist also gelöst. Ich werde die Uhr nicht mehr benutzen und schon läuft wieder alles komplett. Ist zwar schade, aber ich kann damit leben. Im Floorplan kann ich die Uhr noch nutzen und somit ist das für mich ok.
Fall erledigt - Dank für die Unterstützung.
Du könntest probiien, ob es eventuell an der Datei liegt. Also einfach sich "neu besorgen" ..
Hat leider nicht geholfen.