FHEM startet nach Erstinstallation und Reboot nicht mehr

Begonnen von stehoub, 01 November 2016, 01:45:15

Vorheriges Thema - Nächstes Thema

stehoub

Hallo Zusammen,
bin im Raspi und FHEM Neuling und habe das Problem, das nach der Installation und
einem Restart/Ausschalten vom RaspPi FHEM nicht mehr erreichbar ist.
Ich brauche Hilfe, wo mein Fehler ist, da ich das nicht selber gelöst bekomme.
Habe die Installation jetzt schon mehrfach (4 Mal) durchgeführt und
jedes Mal startet FHEM nach einem Reboot nicht mehr.

Hardware:
* RaspPi B+
* 16GB SDHC Karte von Sandisk (auch schon mit einer NoName 2GB karte probiert)
* Netzwerk über Kabel und DHCP
* kein Gerät an den USB Ports vom RaspPi angeschlossen

Software:
* Raspbian-jessie-lite Image: 2016-09-23
* Image Software Win32Disk Imager

Der RaspPi bekommt über eine Reservierung eine feste IP bei mir
192.168.x.40 - Anmeldename und Passwort habe ich (noch) nicht geändert. (pi/raspberry)

Über Putty verbunden
"lsb_release -a" gibt mir als Ergebnis: Raspbian GNU/Linux 8.0 (jessie)

folgende Befehle abgefeuert:
sudo dpkg-reconfigure tzdata
sudo bash
sudo apt-get -y install apt-transport-https
wget -O - https://debian.fhem.de/archive.key | apt-key add -
echo "deb https://debian.fhem.de/stable ./" | sudo tee /etc/apt/sources.list.d/pms.list
sudo apt-get update
sudo apt-get -y upgrade
sudo apt-get -y autoremove
sudo apt-get -y install fhem


Danach kann ich über http://192.168.x.40:8083 auf FHEM zugreifen
und bekomme die normale Webseite (fhem (5.7.)) angezeigt.
Änderungen am System und/oder fhem.cfg habe ich nicht vorgenommen.

Wenn ich dann den RaspPi durchstarte (sudo shutdown -r now) kann ich nicht mehr auf die Webseite zugreifen.

Der FHEM Dienst läuft und scheint auch Ausgabe in der Kommandozeile OK zu sein.
(systemctl status fhem.service)
fhem.service - LSB: FHEM server
  Loaded: loaded (/etc/init.d/fhem)
   Active: active (running) since Tue 2016-11-01 01:30:19 CET; 1min 57s ago
  Process: 336 ExecStart=/etc/init.d/fhem start (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/fhem.service
           └─462 perl fhem.pl fhem.cfg


Wenn ich den Dienst beende (sudo /etc/init.d/fhem stop) bekomme ich
weiterhin mit "systemctl status fhem.service" die Meldung, das der Dienst noch läuft.
Wenn ich den Dienst dann wieder starte, erhalte ich im Logfile "telnetPort: Can't open server port at 7072: Address already in use. Exiting."

Was mache ich falsch??? :-\

Danke schon mal für Eure Tipps...
Stephan

juergen012

Hallo, stimmt die Uhrzeit?? FHEM läuft nur, wenn der Raspi eine Internetverbindung hat und die Uhrzeit gestellt wird.

Gruß
Jürgen K.
Fhem unter Proxmox

CoolTux

Und was ist wenn du fhem mit systwmctl Stop fhem beendest und dann mit Start wieder startest?
Was ergibt ein ps ax | grep perl
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

mickey001


mickey001


Hollo

Auch wenn ich zur Lösung gerade keine Idee habe, möchte ich trotzdem meinen Senf dazu geben:

Ein großes Lob an den Fragesteller; für den 1. Beitrag eine hervorragende Auflistung der Problembeschreibung und der einzelnen Schritte, die durchgeführt wurden.   Finde ich Top  :)

Die Vorgehensweise sieht eigentlich korrekt aus, spontan fallen mir 2 Dinge ein...
1. ein frisches Jessie nutzt ja nicht init.d , ist das im Install-Repository von betateilchen berücksichtigt?
2. da gab es was mit Perl-Version und 100% Last
FHEM 6.x auf RPi 3B Buster
Protokolle: Homematic, Z-Wave, MQTT, Modbus
Temp/Feuchte: JeeLink-Clone und LGW mit LaCrosse/IT
sonstiges: Linux-Server, Dreambox, "RSS-Tablet"

stehoub

Hallo Ihr,
danke für Eure schnellen und tollen Antworten..
Lösung war das der Perl Prozess auf fast 100% ging.
Ein "Sleep 20s" in der /etc/init.d/fhem hat Abhilfe geschaffen. Danke Mickey001
(https://forum.fhem.de/index.php/topic,41823.msg380421.html#msg380421)

Die Uhrzeit und die anderen Tipps aus den vielen Einträgen hier im Forum
hatte ich schon ausprobiert und ausgeschlossen.

Hollo - ich bin selber im IT Support tätig,
ich weiß, wie gut es ist, wenn die Fehlerbeschreibung ausführlich und klar ist :-)

Vielen Dank Euch allen.

Jetzt kann ich mich mal an die Einbindung vom Pilight begeben.
Hab ich da ähnliches zu erwarten?  :D
(Ich bau auf jeden Fall das Autobackup ein ;-) )

Allen noch einen schönen und ruhigen Feiertag.
Stephan

Wernieman

Ich glaube, das Problem ist durch die 20s Wartezeit nur "verschoben", was für Abhängigkeiten sind denn in der Systemdconf für fhem hinterlegt?
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

stehoub

Hallo Werniemann.

Wie gesagt, ich habe eine jungfräulich Installation ohne Zutun von mir durchgeführt.
Die einzelnen Schritte hatte ich ja schon oben erwähnt.
Was da in welchen Abhängigkeiten vom FHEM vielleicht gestartet wird und dann hängen bleibt
entzieht sich meiner Kenntnis (Mangels tieferem Wissen, da ich FHEM erst ein paar Tage kenne)

Stephan

Wernieman

Da ich bei mir FHEM "manuell" installiert habe, weiß ich nicht, was genau am Anfang der /etc/init.d/fhem steht.
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Otto123

Zitat von: Wernieman am 01 November 2016, 20:47:19
Ich glaube, das Problem ist durch die 20s Wartezeit nur "verschoben", was für Abhängigkeiten sind denn in der Systemdconf für fhem hinterlegt?
Hallo Stephan,

ich habe das Problem  mit den Abhängigkeiten in meinem Artikel beschrieben. So läuft es bei mir sauber. --> Abschnitt Feintuning.
Das Problem tritt scheinbar bloß bei bestimmten Situationen zu Tage, bei mir war es nach der Installation des HM RPI Moduls.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz