FHEM Forum

Hallo Zusammen,

ich poste das mal im Anfängerfiorum, da ich diesen Status noch habe.

Fhem läuft bereits seit Wochen, 1-Wire Sensoren und Ultraschall über GPIO angeschaltet.
Ich habe eben nichts wildes gemacht: Pushover eingerichtet.

Habe einen Neustart des Pi gemacht, und habe nun keinen Zugriff mehr auf die Weboberfläche.
Der FHEM-Dienst läuft. Allerdings werden die Logs der Fühler nicht mehr geschrieben, alle haben den Stand von vor dem Neustart.
Komischerweise kann ich den Dienst auch nicht beenden, er bleibt immer im Status "running"

Die letzten Einträge der fhem.log:

2017.01.26 09:30:07 1: Including fhem.cfg
2017.01.26 09:30:07 3: telnetPort: port 7072 opened
2017.01.26 09:30:07 3: WEB: port 8083 opened
2017.01.26 09:30:07 3: WEBphone: port 8084 opened
2017.01.26 09:30:07 3: WEBtablet: port 8085 opened
2017.01.26 09:30:08 2: eventTypes: loaded 138 events from ./log/eventTypes.txt
2017.01.26 09:30:08 3: TABLETUI: new ext defined infix:ftui/: dir:./www/tablet:
2017.01.26 09:30:08 3: Registering HTTPSRV TABLETUI for URL /ftui   and assigned link ftui/ ...
2017.01.26 09:30:08 1: Including ./log/fhem.save
2017.01.26 09:30:08 1: usb create starting
2017.01.26 09:30:08 3: Probing CUL device /dev/ttyAMA0
2017.01.26 09:30:09 3: Probing TCM_ESP3 device /dev/ttyAMA0
2017.01.26 09:30:09 3: Probing FRM device /dev/ttyAMA0
2017.01.26 09:30:15 1: usb create end
2017.01.26 09:30:15 3: myOWFS: Opening connection to OWServer 127.0.0.1:4304...
2017.01.26 09:30:15 3: myOWFS: Successfully connected to 127.0.0.1:4304.

Für mein Gefühl bleibt er da stehen. Kann jemand was dazu sagen?
Vielen Dank

Hi,

klingt als rennt er in eine Endlosschleife. Die CPU macht 100% ? top gibt Dir Auskunft.

Ich würde versuchen die letzten Änderungen rückgängig zu machen.

Gruß Otto

Das sieht nicht so aus, als wäre die CPU stark belastet.
Ich hatte bereits die fhem.cfg von gestern eingespielt: das gleiche Bild

root@raspberrypi:/opt/fhem/log# top
top - 10:04:38 up 34 min,  1 user,  load average: 0.02, 0.01, 0.00
Tasks: 111 total,   1 running, 110 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.1 us,  0.1 sy,  0.0 ni, 99.8 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem:    947748 total,   116496 used,   831252 free,    10128 buffers
KiB Swap:   102396 total,        0 used,   102396 free.    53884 cached Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
  973 root      20   0    5112   2480   2104 R   0.7  0.3   0:00.31 top
    1 root      20   0    5496   3848   2676 S   0.0  0.4   0:03.44 systemd
    2 root      20   0       0      0      0 S   0.0  0.0   0:00.00 kthreadd
    3 root      20   0       0      0      0 S   0.0  0.0   0:00.06 ksoftirqd/0
    5 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 kworker/0:0H
    6 root      20   0       0      0      0 S   0.0  0.0   0:00.07 kworker/u8:0
    7 root      20   0       0      0      0 S   0.0  0.0   0:00.19 rcu_sched
    8 root      20   0       0      0      0 S   0.0  0.0   0:00.00 rcu_bh
    9 root      rt   0       0      0      0 S   0.0  0.0   0:00.00 migration/0
   10 root      rt   0       0      0      0 S   0.0  0.0   0:00.00 migration/1
   11 root      20   0       0      0      0 S   0.0  0.0   0:00.01 ksoftirqd/1
   13 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 kworker/1:0H
   14 root      rt   0       0      0      0 S   0.0  0.0   0:00.00 migration/2
   15 root      20   0       0      0      0 S   0.0  0.0   0:00.00 ksoftirqd/2
   17 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 kworker/2:0H
   18 root      rt   0       0      0      0 S   0.0  0.0   0:00.00 migration/3
   19 root      20   0       0      0      0 S   0.0  0.0   0:00.00 ksoftirqd/3
   21 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 kworker/3:0H
   22 root      20   0       0      0      0 S   0.0  0.0   0:00.00 kdevtmpfs
   23 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 netns
   24 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 perf
   25 root      20   0       0      0      0 S   0.0  0.0   0:00.00 khungtaskd
   26 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 writeback
   27 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 crypto
   28 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 bioset
   29 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 kblockd
   31 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 rpciod
   32 root      20   0       0      0      0 S   0.0  0.0   0:00.00 kswapd0


Kannst Du den Start von FHEM mal bitte vom ntp abhängig machen und dann nochmal neu starten?
Für das ssh Terminal: bitte besonders die lange Zeile exakt so kopieren! Oder von mir aus auch die Änderung mit nano machen.
sudo su
sed -i s/'# Required-Start:       $local_fs $remote_fs/# Required-Start:       $local_fs $remote_fs $ntp/' /etc/init.d/fhem
systemctl daemon-reload
Näheres hier
http://heinz-otto.blogspot.de/2016/09/fhem-in-wenigen-schritten.html

Gruß Otto

Entweder habe ich Tomaten auf den Augen oder ich sehe da keinen FHEM (bzw. Pearl)-Task?!?

Was sagt denn ein lapidares sudo service fhem status?!? Tippe mal auf ein Exited?!

Der fhem-Dienst war weiter unten. Und der Status war running. Das komisch war: auch nach dem stoppen des Dienstes war der Status auf running.
Und jetzt kommt es ganz komisch: plötzlich geht fhem wieder...

Im Fehlerzustand war das der letzte EIntrag im Log:
2017.01.26 09:30:15 3: myOWFS: Successfully connected to 127.0.0.1:4304.

Jetzt wo es geht sieht es so aus:
2017.01.26 13:55:37 3: myOWFS: Successfully connected to 127.0.0.1:4304.
2017.01.26 13:55:43 0: Featurelevel: 5.7
2017.01.26 13:55:43 0: Server started with 68 defined entities (fhem.pl:13210/2017-01-23 perl:5.020002 os:linux user:fhem pid:14467)
2017.01.26 13:56:30 3: telnetForBlockingFn_1485435390: port 39413 opened


Jemand eine Idee was das war?

...und siehe da: einen Neustart gemacht und das Problem ist wieder da. fhem läuft nicht.

Der letzte Log-Eintrag ist wieder dieser:
2017.01.26 09:30:15 3: myOWFS: Successfully connected to 127.0.0.1:4304.

wenn du in FHEM nicht mehr rein kommst gibt es verschiedene Möglichkeiten:

- Backup einspielen, welches eine funktionierende Version ist
- Wenn du meinst, dass es an myOWFS liegt, kannst du in die cfg Datei gehen und es mal löschen/auskommentieren und schauen, ob es dann startet
- Verbose in der cfg mal auf 5 stellen und starten um zu sehen was noch passiert beim Start. Vll liegt es ja nicht an myOWFS

Deswegen ja auch meine Frage oben was sudo service fhem status ausgibt...

Zitat von: M.Piet am 26 Januar 2017, 14:08:56
...und siehe da: einen Neustart gemacht und das Problem ist wieder da. fhem läuft nicht.

Der letzte Log-Eintrag ist wieder dieser:

Code Auswählen Erweitern

2017.01.26 09:30:15 3: myOWFS: Successfully connected to 127.0.0.1:4304.

Das ist aber ein alter Eintrag  :-X

Hast Du das mit der Dienstabhängigkeit probiert?

Gruß Otto

Hallo Zusammen,

vielen Dank für die Antworten.

ZitatBackup einspielen, welches eine funktionierende Version ist

Das hatte ich getan. Selbst damit kam FHEM nicht wieder komplett hoch.

ZitatDeswegen ja auch meine Frage oben was sudo service fhem status ausgibt...

Hatte doch oben geschrieben, dass der Status auf Running stand.

Ich denke ich habe den Fehler gefunden. Als ich gestern nach Hause kam, war ich verwundert das FHEM wieder geht, aber alle 1-wire Fühler keine Werte lieferten, und die Logs voll waren mit Fehler zu den Fühlern.

Und zwischen diesen beiden Einträgen war eine zeit von ca. 1,5 Stunden:

2017.01.26 15:15:07 3: myOWFS: Successfully connected to 127.0.0.1:4304.
2017.01.26 17:56:12 0: Featurelevel: 5.7

Ich habe daraufhin den Pi runtergefahren, ihn und den angeschlossenen USB-Hub (an dem der 1wire Hostcontroller hängt) stromlos gemacht, gebootet. Und siehe da...es geht wieder. Ich vermute ein Problem mit dem USB-Hub oder dem Controller.
Ich werde das mal weiter beobchten.
Danke für eure Hilfe. :)

Naja, Du hast geschrieben

ZitatDer fhem-Dienst war weiter unten. Und der Status war running. Das komisch war: auch nach dem stoppen des Dienstes war der Status auf running.

Und das machte mich stutzig. Deswegen ja auch die explizite Frage nach dem Staus des Dienstes. Aber seis drum, läuft ja wieder.

Du hast recht. Ich habe Mist geschrieben.
Ich wollte sagen: der Webzugriff ging nicht, aber der Dienst war oben. :) Bin halt auch schon über 40...

Kein Problem - und das Alter ist egal, werde ich im Juni auch ;)

OK, ich habe mein Problem gelößt. Wollte euch das gern mitteilen, vielleicht hilft es wem anders, der das gleiche Problem hat.

Gestern musste ich den Pi das erste mal wieder neu starten. Und das gleiche Problem wieder. FHEM-Dienst ist oben, aber keine Weboberfläche.
Bleibt laut Log wieder nach dem Eintrag hängen:
myOWFS: Successfully connected to 127.0.0.1:4304.
Ziehe ich den USB-Stecker ab, kommt fhem immer sofort hoch. Ich vermute das der fhem-Dienst zu schnell startet, und der USB-Dongle vom 1wire noch nicht fertig initialisiert ist.

Ich habe folgende Änerung vorgenommen:

Folgende Zeile in der /etc/init.d/fhem eingefügt:
sleep 10
(vor den Zeilen in den fhem geladen wird)

Dieses wurde auch schon mehrfach hier diskutiert. Es gibt Abhängigkeiten, die der FHEM-Init-Prozess nicht berücksichtigt.

Und fürs Debuggen ist folgende Vorgehensweise besser:
https://forum.fhem.de/index.php/topic,54271.msg467373.html#msg467373 (https://forum.fhem.de/index.php/topic,54271.msg467373.html#msg467373)