GUI reagiert nach Re- /Start nicht

[birdy]

Immer wenn ich meinen Raspi neu starte reagiert das GUI erstmal nich.
Wenn ich mich mit Putty einlogge sehe ich dass FHEM läuft, aber 99.9% der Systemressourcen benötigt. Nachdem ich dann FHEM neu gestartet habe (systemctl stop fhem / systemctl start fhem) ist das Problem gelöst. Ich vermute, dass das Problem an falschen Berechtigungen liegt. 
Raspian habe ich mit den Setup-Assistenten auf der Karte eingerichtet. Dabei habe ich meinen "eigenen" Admin-User eingerichtet. Diesen verwende ich auch für das SSH Login, einen andren Login (z.B. root habe ich nicht).

Mit dieser Seite (https://wiki.fhem.de/wiki/FHEM_startet_nicht_-_Tipps_zur_Fehlersuche) kann ich das Problem nur temporär aber nicht dauerhaft lösen.

Hat jemand eine Idee wie ich mein Problem lösen kann?

[Otto123]

Wenn so

Ich vermute, dass das Problem an falschen Berechtigungen liegt. 

Dann so
https://wiki.fhem.de/wiki/FHEM_startet_nicht_-_Tipps_zur_Fehlersuche#Pr.C3.BCfen:_Stimmen_die_Dateiberechtigungen.3F

Die temporäre Lösung habe ich nicht verstanden

[birdy]

Hallo Otto

Vielen Dank für Deine Rückmeldung.

Wie in meinem ersten Post schon erwänt habe, löst folgndes mein Problem nicht.

https://wiki.fhem.de/wiki/FHEM_startet_nicht_-_Tipps_zur_Fehlersuche#Pr.C3.BCfen:_Stimmen_die_Dateiberechtigungen.3F

Darum schreibe ich hier.

Nach einem Reboot oder wenn der Raspi weg von Strom war und bootet, läuft FHEM erst mal mit 100% und das GUI reageiert nicht.

Meine temporäre Lösung:  Lich loge mich nach jedem Restart des Raspi mit meinen einzigen und zugleicht Amdin User (nicht root) ein.
Ich beende FHEM und starte es wieder neu (systemctl stop fhem / systemctl start fhem). Nach diesem Re-Start läuft FHEM normal und das GUI regiert weider.

Offensichtlich macht es einen Unterschied ob FHEM wärend dem Bootvorgang automatisch, oder durch mich manuell gestaret wird.

Gruss birdy

[Otto123]

na gut - aber warum verwirrst Du mich dann mit der Annahme das es an Berechtigungen liegt?

Also dein System rennt nach einem Kaltstart mit 100% und mit einem Warmstart wird das Problem behoben.

Was findet man danach im Log vom Zeitpunkt des Kaltstarts?
Sind USB Geräte angeschlossen? Werden Datenbanken verwendet? Wird Bluetooth verwendet? Sind Netzlaufwerke verbunden?
Wie hast Du FHEM installiert?

Idee:
Irgendwas wird  benötigt ist aber beim Kaltstart noch nicht am Laufen: Man sollte Abhängigkeiten einbauen

Kannst Du mal probehalber eine Startverzögerung einbauen? https://wiki.fhem.de/wiki/Fhem.service_(systemd_unit_file)#Start_verz.C3.B6gern

Gruß Otto

[birdy]

Hallo Otto
Ich habe Dich nicht extra verwirrt. Meine Annahm ist, dass es an den Berechtigungen liegt. So wie Du annimmst, dass es am Kaltstart liegt.
Zu deinen Fragen: Unten das Log
An USB hängt nur ein Wifi Dongle. Keine DB's, Kein Bluetooth. Keine Netzlaufwerke.
Wie ich FHEM installiert habe weiss ich nicht mehr, liegt schon länger zurück. Muss aber gem. Anleitung gewesen sein. Raspi ist nun längere durchgelaufen. Hatte aber kürzlich ein Stromausfall. Nach den Kaltstart, hat es eine Weile gedauert bis es mir wieder in den Sinn gekommen ist wie ich das jeweils löse.

Auch mit Startverzögerung ist FHEM nach 60sek wieder auf 100% CPU Last. (??)

Code Auswählen Erweitern

>systemctl show fhem.service -p TimeoutStartUSec
TimeoutStartUSec=6min

Hier zuerst ein Kaltstart und danach ein Warmstart

Code Auswählen Erweitern

2022.11.29 20:04:07 1: Including fhem.cfg
2022.11.29 20:04:07 3: telnetPort: port 7072 opened
2022.11.29 20:04:08 3: WEB: port 8083 opened
2022.11.29 20:04:08 3: WEBphone: port 8084 opened
2022.11.29 20:04:08 3: WEBtablet: port 8085 opened
2022.11.29 20:04:08 2: eventTypes: loaded 2 lines from ./log/eventTypes.txt
2022.11.29 20:04:08 1: Including ./log/fhem.save
2022.11.29 20:04:08 1: Messages collected while initializing FHEM:SecurityCheck:
  WEBphone is not password protected
  WEB is not password protected
  WEBtablet is not password protected
  telnetPort is not password protected

Protect this FHEM installation by configuring the allowed device allowed
You can disable this message with attr global motd none

2022.11.29 20:04:08 1: usb create starting
2022.11.29 20:04:08 3: Probing ZWDongle device /dev/serial0
2022.11.29 20:04:09 3: Probing ZWDongle device /dev/serial1
2022.11.29 20:04:09 1: PERL WARNING: can't getattr: Input/output error at FHEM/DevIo.pm line 612.
2022.11.29 20:04:09 1: ZWDongle: Can't open /dev/serial1: Input/output error
2022.11.29 20:04:09 3: Probing CUL device /dev/ttyAMA0
2022.11.29 20:04:09 3: Probing TCM_ESP3 device /dev/ttyAMA0
2022.11.29 20:04:09 3: Probing ZWDongle device /dev/ttyAMA0
2022.11.29 20:04:09 3: Probing SIGNALDuino device /dev/ttyAMA0
2022.11.29 20:04:09 3: Probing MYSENSORS device /dev/ttyAMA0
2022.11.29 20:04:10 3: Probing ArduCounter device /dev/ttyAMA0
2022.11.29 20:04:10 3: Probing ElsnerWS device /dev/ttyAMA0
2022.11.29 20:04:11 3: Probing FRM device /dev/ttyAMA0
2022.11.29 20:07:13 1: Including fhem.cfg
2022.11.29 20:07:13 3: telnetPort: port 7072 opened
2022.11.29 20:07:13 3: WEB: port 8083 opened
2022.11.29 20:07:13 3: WEBphone: port 8084 opened
2022.11.29 20:07:13 3: WEBtablet: port 8085 opened
2022.11.29 20:07:13 2: eventTypes: loaded 2 lines from ./log/eventTypes.txt
2022.11.29 20:07:13 1: Including ./log/fhem.save
2022.11.29 20:07:13 1: Messages collected while initializing FHEM:SecurityCheck:
  WEBtablet is not password protected
  WEB is not password protected
  telnetPort is not password protected
  WEBphone is not password protected

Protect this FHEM installation by configuring the allowed device allowed
You can disable this message with attr global motd none

2022.11.29 20:07:13 1: usb create starting
2022.11.29 20:07:13 3: Probing ZWDongle device /dev/serial0
2022.11.29 20:07:14 1: ZWDongle: Can't open /dev/serial0: Permission denied
2022.11.29 20:07:14 3: Probing ZWDongle device /dev/serial1
2022.11.29 20:07:14 1: PERL WARNING: can't getattr: Input/output error at FHEM/DevIo.pm line 612.
2022.11.29 20:07:14 1: ZWDongle: Can't open /dev/serial1: Input/output error
2022.11.29 20:07:14 3: Probing CUL device /dev/ttyAMA0
2022.11.29 20:07:14 1: CUL: Can't open /dev/ttyAMA0: Permission denied
2022.11.29 20:07:14 3: Probing CUL device /dev/ttyS0
2022.11.29 20:07:14 1: CUL: Can't open /dev/ttyS0: Input/output error
2022.11.29 20:07:14 1: usb create end
2022.11.29 20:07:14 0: Featurelevel: 6.1
2022.11.29 20:07:14 0: Server started with 13 defined entities (fhem.pl:26635/2022-11-01 perl:5.032001 os:linux user:fhem pid:634)


Gruss birdy

[DeeSPe]

Sieht mir danach aus:
https://forum.fhem.de/index.php/topic,66273.msg575546.html#msg575546

Gruß
Dan

[birdy]

Sieht mir danach aus:
https://forum.fhem.de/index.php/topic,66273.msg575546.html#msg575546

Gruß
Dan

Danke Dan. Ja genau das scheint das Problem zu sein. Bei mir dauert dieser USB Create aber nicht Minuten, sondern ewig. Warum sich da ein Warm –Kaltstart so unterschiedlich auswirkt, ist mir schleierhaft.

[Otto123]

Vermutung: weil nach einem kompletten Start der Wlan Stick in Betrieb ist und initialUsbCheck nicht mehr ran kommt um sich "festzubeißen".

[birdy]

Hallo Otto
Ja, so muss es sein. Ich habe einen raspberry pi 3B der für sein instabiles WLAN bekannt ist. Früher hatte ich mit dem integrierten WLAN immer wieder Verbindungsprobleme und ein blockiertes FHEM. Seit dem ich einen USB WLAN Stick verwende, ist die WLAN Verbindung äusserst zuverlässig. Die Probleme mit dem blockierten FHEM waren (wenn auch etwas anders) trotzdem nicht ganz weg. Jetzt weiss ich auch wieso 
Obwohl zwei ganz unterschiedliche Probleme, sie haben sich sehr ähnlich manifestiert. Darum konnte ich diese wohl nicht klar auseinander halten. Danke für die tolle Unterstützung.
Gruss, birdy