FHEM wird beim Neustart des Raspi nicht richtig gestartet, fhem Prozess doppelt

Begonnen von Don Pedro, 15 Januar 2017, 01:18:13

Vorheriges Thema - Nächstes Thema

Don Pedro

Hallo,

ich habe ein ganz ähnliches Problem wie in folgendem Thread:
FHEM lässt sich nicht mehr starten

Mein Problem habe ich dort bereits geschildert, wie ein User aber richtig anmerkte werden das nicht so viele Member lesen, da der Thread schon auf gelöst steht. Daher mache ich hier nochmal einen neuen auf, in der Hoffnung, dass mehr Leute etwas zur Ursache und Beseitigung sagen können.

Was passiert ist, dass nach dem Neustart des Raspi scheinbar immer zwei fhem Prozesse auftstarten, die sich dann gegenseitig die TCP/IP-Ports streitig machen und aussteigen, weil sie z. B. nicht an den Telnet Port binden können. Die beiden Prozesse muss man dann mit kill -9 gewaltsam wegschießen. Startet man danach fhem händisch neu ("/etc/init.d/fhem start") läuft alles OK - bis zum nächsten Neutstart des Raspi. Mehr Details dazu stehen im verlinkten Thread. Hat jemand eine Idee warum sich fhem weghängt, wenn es bei Auftstart des Rechners automatisch gestartet werden soll und wie ich das abgestellt bekomme??

THX

Don

viegener

Wie in dem anderen Thread schonmal geschrieben wäre es gut rauszufinden was passiert wenn Du ohne laufendes FHEM den "normalen" startbefehl für fhem mal ausführst:

perl fhem.pl fhem.cfg

Was passiert dann?
Kein Support über PM - Anfragen gerne im Forum - Damit auch andere profitieren und helfen können

Don Pedro

Zitat von: viegener am 15 Januar 2017, 12:43:25
Wie in dem anderen Thread schonmal geschrieben wäre es gut rauszufinden was passiert wenn Du ohne laufendes FHEM den "normalen" startbefehl für fhem mal ausführst:

perl fhem.pl fhem.cfg

Was passiert dann?

Wie dem anderen Thread auch schon geschrieben:

Zitat von: Don Pedro am 15 Januar 2017, 00:31:07
Naja, es startet eine fhem Instanz. Die Eingabe führt auf der Konsole zu keinerlei weiterer Ausgabe, man bekommt das Prompt zurück und kann dann mit
ps aux | grep [f]hem
kontrollieren dass fhem nun läuft. /etc/init.d/fhem start führt zum gleichen Ergebnis.

Also: fhem läuft bei einem manuellen Start nach obigem Muster dann normal und wie erwartet, ist also über die Weboberfläche ansprechbar. "/etc/init.d/fhem start" ist ja das was ich behelfsmäßig nach dem kill -9 mache um fhem wieder laufen zu lassen - bis zum nächsten Neustart des Raspi.

THX

Don

viegener

OK, also ist es erstmal kein FHEM-Problem?
Und es tritt nur beim Systemstart auf?
Die Vermutung ist also, dass Du irgendetwas auf Deinem System eingerichtet hast, dass beim Neustart einen Fehler macht

Das war jetzt langwierig dahin zukommen - Es ist irgendwie schwierig Informationen zu bekommen

Woher stammt denn das init.d skript und was steht da drin?
Gibt es vielleicht noch andere Überwachungsskripte?
Gibt es vielleicht noch andere Skripte in init.d

Du musst vielleicht mal während des Systemstarts schauen wie es zu dem doppelten Start kommt?

Kein Support über PM - Anfragen gerne im Forum - Damit auch andere profitieren und helfen können

Marlen

Hab auch manchmal das Problem das nach einen reboot, alles total langsam läuft und ich kaum noch zugreifen kann!

Wie sieht man das 2 Instanzen laufen?

LG
  Marlen

Don Pedro

Zitat von: viegener am 24 Januar 2017, 00:36:42
Das war jetzt langwierig dahin zukommen - Es ist irgendwie schwierig Informationen zu bekommen

Woher stammt denn das init.d skript und was steht da drin?
Gibt es vielleicht noch andere Überwachungsskripte?
Gibt es vielleicht noch andere Skripte in init.d

init.d ist einfach nur die Standardinstallation die mit Debian/Jessy auf dem Raspi mitkommt. Zusätzlich installiert wurden nur syncthing (mein automatisiertes Backup) und minidlna (um Musik auf einem USB-Stick im Netzwerk bereitzustellen). Sonst habe ich am init-System nichts geändert, es gibt sonst m. W. auch keine anderen Skripte, sorry.

Zitat von: viegener am 24 Januar 2017, 00:36:42
Du musst vielleicht mal während des Systemstarts schauen wie es zu dem doppelten Start kommt?

Was muss ich dazu tun?

THX

Don

CoolTux

Schon 3 Posts und noch kein einziger Logfile Eintrag.
Ich hole Mal was um die Glaskugel zu polieren.
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

Don Pedro

Zitat von: Marlen am 24 Januar 2017, 11:52:14
Hab auch manchmal das Problem das nach einen reboot, alles total langsam läuft und ich kaum noch zugreifen kann!

Hört sich für mich aber nach einem anders gelagerten Problem an. In meinem Fall ist die Weboberfläche definitiv gar nicht ansprechbar.

Zitat von: Marlen am 24 Januar 2017, 11:52:14
Wie sieht man das 2 Instanzen laufen?

ps aux | grep [f]hem
zeigt dir alles laufende an, was sich irgendwie "fhem" oder "hem" schimpft.
Du solltest eine Ausgabe bekommen die ungefähr so aussieht:

xxx@Raspberry-Pi-2:/etc/init.d# ps aux | grep [f]hem
root      2859  0.0  0.1   4772  1984 pts/1    S+   23:04   0:00 grep fhem
fhem     23086  0.4  5.4  59584 54592 ?        S    Jan15  85:41 perl fhem.pl fhem.cfg
fhem     23111  0.0  3.6  43068 36216 ?        Ss   Jan15   0:44 perl fhem.pl fhem.cfg

Die erste Zeile ist nicht das Problem, das ist das grep-Kommando was du gerade abgesetzt hast und dort taucht natürlich fhem auch auf. Darunter dann die beiden fhem-Prozesse.

Interessanterweise sind die zwei fhem Prozesse aber wohl nicht das ganze Problem, denn die sehe ich auch, wenn auf fhem zugegriffen werden kann. So ganz verstehe ich's nicht...

BR

Don

CoolTux

Es gibt Module die verwenden einen Fork um NonBlocking Zeitintensive Aufgaben zu erledigen. Diesen Fork sieht man dann als zweiten fhem Prozess. Der sollte aber nach einiger Zeit wieder verschwinden.
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

Don Pedro

Zitat von: CoolTux am 28 Januar 2017, 23:10:52
Schon 3 Posts und noch kein einziger Logfile Eintrag.
Ich hole Mal was um die Glaskugel zu polieren.

Hier ist mal ein Log, Mr. Glaskugel:

2017.01.08 22:56:57 1: Including fhem.cfg
2017.01.08 22:56:58 1: telnetPort: Can't open server port at 7072: Die Adresse wird bereits verwendet. Exiting.


Das war's, mehr kommt zu diesem Startversuch nicht!! Fhem behauptet hier zwar "exiting", der Prozess beendet sich aber offenbar gar nicht, sondern man muss dem mit kill -9 zu Leibe rücken.

Nachdem ich an der Konfiguration rumgespielt habe sieht das Log dann etwas anders aus (die irrelevanten Details wie "Device xxx added to ActionDetector" oder "CUL_HM set yyy getConfig" habe ich der Übersichtlichkeit halber mal aus dem Log weggestrippt). Man beachte die Meldungen bzgl. Nichterreichbarkeit des Netzwerkes (die korrkekterweise heißen müsste, dass nicht an den TCP/IP-Port gebunden werden kann, weil schon jemand anderes draufhockt, nämlich die zweite fhem Instanz).


2017.01.08 23:28:03 1: Including fhem.cfg
2017.01.08 23:28:04 3: telnetPort: port 7072 opened
2017.01.08 23:28:04 3: WEB: port 8083 opened
2017.01.08 23:28:04 3: WEBphone: port 8084 opened
2017.01.08 23:28:04 3: WEBtablet: port 8085 opened
2017.01.08 23:28:05 2: eventTypes: loaded 2456 events from ./log/eventTypes.txt
2017.01.08 23:28:05 1: HMLAN_Parse: Homematic_HM_CFG_LAN new condition disconnected
2017.01.08 23:28:05 3: Opening Homematic_HM_CFG_LAN device 192.168.178.30:1000
2017.01.08 23:28:05 3: Can't connect to 192.168.178.30:1000: Das Netzwerk ist nicht erreichbar
2017.01.08 23:28:07 3: [Twilightcalculation] got no weather info from yahoo. Error code: http://query.yahooapis.com/v1/public/yql?q=select%20*%20from%20weather.forecast%20where%20woeid=12833231%20and%20u=%27c%27&format=json&env=store%3A%2F%2Fdatatables.org%2Falltableswithkeys: Can't connect(1) to http://query.yahooapis.com:80: IO::Socket::INET: Bad hostname 'query.yahooapis.com:80'
2017.01.08 23:28:08 3: Opening FritzBox_1_Anrufe device 192.168.178.1:1012
2017.01.08 23:28:08 3: Can't connect to 192.168.178.1:1012: Das Netzwerk ist nicht erreichbar
2017.01.08 23:28:08 3: Can't connect to 192.168.178.1:1012: connect to http://192.168.178.1:1012: Das Netzwerk ist nicht erreichbar
2017.01.08 23:28:08 3: FB_CALLMONITOR (FritzBox_1_Anrufe) - loading cache file /usr/share/fhem/telefonbuch.txt
2017.01.08 23:28:08 2: FB_CALLMONITOR (FritzBox_1_Anrufe) - read no contacts from Cache
2017.01.08 23:28:09 2: fronthem: ipc listener opened at port 16384
2017.01.08 23:28:09 1: Including ./log/fhem.save
2017.01.08 23:28:12 3: FB_CALLMONITOR (FritzBox_1_Anrufe) - error while requesting phonebooks: http://192.168.178.1:49000/upnp/control/x_contact: Can't connect(1) to http://192.168.178.1:49000: IO::Socket::INET: connect: Das Netzwerk ist nicht erreichbar
2017.01.08 23:28:12 2: FB_CALLMONITOR (FritzBox_1_Anrufe) - could not identify remote phonebooks - error while requesting phonebooks: http://192.168.178.1:49000/upnp/control/x_contact: Can't connect(1) to http://192.168.178.1:49000: IO::Socket::INET: connect: Das Netzwerk ist nicht erreichbar
2017.01.08 23:28:12 1: in INITIALIZED
2017.01.08 23:28:12 1: usb create starting
2017.01.08 23:28:13 3: Probing CUL device /dev/ttyAMA0
2017.01.08 23:28:13 3: Probing TCM_ESP3 device /dev/ttyAMA0
2017.01.08 23:28:13 3: Probing FRM device /dev/ttyAMA0


Das sind aber alles nur Symptome, nämlich dass sich hier zwei Prozesse in die Quere kommen und versuchen die gleichen Ressourcen zu belegen.

BR

Don

viegener

Zitat von: Don Pedro am 28 Januar 2017, 23:03:52
init.d ist einfach nur die Standardinstallation die mit Debian/Jessy auf dem Raspi mitkommt. Zusätzlich installiert wurden nur syncthing (mein automatisiertes Backup) und minidlna (um Musik auf einem USB-Stick im Netzwerk bereitzustellen). Sonst habe ich am init-System nichts geändert, es gibt sonst m. W. auch keine anderen Skripte, sorry.


Erstmal zur Wiederholung, Du hast wohl kein FHEM-Problem sondern ein Problem auf Linux-Ebene.

Ist irgendwie weiterhin sehr mühsam.

Ahh Jessie - Kann es sein, dass Du die Anleitungen zur systemd-Autostart befolgt hast (ohne dies initd-Starts zu deaktivieren)?

Ansonsten - init.d ist ein Verzeichnis, ja das kommt bereits mit der Debian-Installation. Es geht aber um das Skript in diesem Verzeichnis, denn das wird ja beim Systemstart ausgeführt - stammt das aus der fhem-Debian installation?

Ist ein Eintrag in der rc.local?

Kein Support über PM - Anfragen gerne im Forum - Damit auch andere profitieren und helfen können

Prof. Dr. Peter Henning

ZitatSonst habe ich ... nichts geändert
Das ist die typische Behauptung, die eben nicht zutrifft. Hier wurde offenbar händisch an der Startkonfiguration manipuliert, das muss man dann eben mal rückgängig machen oder richtig machen.

LG

pah

Don Pedro

Zitat von: viegener am 29 Januar 2017, 02:06:05
Erstmal zur Wiederholung, Du hast wohl kein FHEM-Problem sondern ein Problem auf Linux-Ebene.

Maybe, habe ich weder bestritten noch behauptet. Versuche halt die Ursache des Problems herauszufinden, wenn ich wüsste wo ich suchen muss, müsste ich hier nicht fragen.

Zitat von: viegener am 29 Januar 2017, 02:06:05
Ist irgendwie weiterhin sehr mühsam.

Möglich. Sorry wenn ich mich bei der Beantwortung deiner Fragen etwas dappich anstelle. Hab vlt. nicht verstanden was du an Infos brauchst oder du hast es für meinen (begrenzten) Wissensstand nicht klar genug gesagt.

Zitat von: viegener am 29 Januar 2017, 02:06:05
Ahh Jessie - Kann es sein, dass Du die Anleitungen zur systemd-Autostart befolgt hast (ohne dies initd-Starts zu deaktivieren)?

Dunno! Ich habe fhem so installiert wie hier beschrieben:
http://www.meintechblog.de/2016/05/fhem-server-auf-dem-raspberry-pi-in-weniger-als-einer-stunde-einrichten
(Also so: "sudo apt-get install fhem" und noch ein paar weitere "sudo apt-get install ..." für NTP-Server, JSON, telnet, etc., was sonst halt noch auf den Raspi drauf sollte)
und dann nach meinen Bedürfnissen über die Weboberfläche eingerichtet. Händisch an den Startmechanismen von fhem habe ich nicht gefummelt, nicht in initd und auch nicht in systemd.

Zitat von: viegener am 29 Januar 2017, 02:06:05
Ansonsten - init.d ist ein Verzeichnis, ja das kommt bereits mit der Debian-Installation.

Ist bekannt.

Zitat von: viegener am 29 Januar 2017, 02:06:05
Es geht aber um das Skript in diesem Verzeichnis, denn das wird ja beim Systemstart ausgeführt - stammt das aus der fhem-Debian installation?

So ist es. in /etc/init.d liegt ein Skript "fhem", dieses stammt aus der Debian Installation und wurde von mir nicht modifiziert.

Zitat von: viegener am 29 Januar 2017, 02:06:05
Ist ein Eintrag in der rc.local?

?? Was müsste ich dort sehen? Die /etc/init.d/rc.local ist bei mir ein Skript. Das sieht so aus:


#! /bin/sh
### BEGIN INIT INFO
# Provides:          rc.local
# Required-Start:    $all
# Required-Stop:
# Default-Start:     2 3 4 5
# Default-Stop:
# Short-Description: Run /etc/rc.local if it exist
### END INIT INFO


PATH=/sbin:/usr/sbin:/bin:/usr/bin

. /lib/init/vars.sh
. /lib/lsb/init-functions

do_start() {
        if [ -x /etc/rc.local ]; then
                [ "$VERBOSE" != no ] && log_begin_msg "Running local boot scripts (/etc/rc.local)"
                /etc/rc.local
                ES=$?
                [ "$VERBOSE" != no ] && log_end_msg $ES
                return $ES
        fi
}

case "$1" in
    start)
        do_start
        ;;
    restart|reload|force-reload)
        echo "Error: argument '$1' not supported" >&2
        exit 3
        ;;
    stop|status)
        # No-op
        exit 0
        ;;
    *)
        echo "Usage: $0 start|stop" >&2
        exit 3
        ;;
esac


und /etc/rc.local ist ebenfalls ein Skript und sieht so aus:


#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

# Print the IP address
_IP=$(hostname -I) || true
if [ "$_IP" ]; then
  printf "My IP address is %s\n" "$_IP"
fi

exit 0


Beide Skripte habe ich nicht angefasst. Was für einen Eintrag erwartest du hier?

THX

Don

Don Pedro

Zitat von: Prof. Dr. Peter Henning am 29 Januar 2017, 05:47:34
Das ist die typische Behauptung, die eben nicht zutrifft. Hier wurde offenbar händisch an der Startkonfiguration manipuliert, das muss man dann eben mal rückgängig machen oder richtig machen.

Wenn man meint in der Kategorie "Anfängerfragen" vlt. nicht so erfahrenen Anwendern über den Mund und fahren zu müssen, zwar sagt, dass man etwas korrigieren/rückgängig/richtig machen müsse, aber mit keinem Wort verrät wie und was und außerdem unterstellt, dass der Anwender "heimlich" an der Konfiguration herumgefummelt hat, es hier aber nicht öffentlich zugeben will, dann finde ich das offen gesagt nicht sonderlich hilfreich/konstruktiv!  :-\

Ich habe mir die einzelnen Schritte die ich bei der Installation des Raspi durchgeführt habe notiert (damit ich im Fall dass mir das Ding mal wegraucht schnell ein neues System aufsetzen kann), kann das also nachkontrollieren was dort gelaufen ist. Die Skripte die zusätzlich zur Standardinstallation ("Jessie light" von https://www.raspberrypi.org/downloads/raspbian/) in etc/init.d gelandet sind, sind dort durch ein "sudo apt-get install ..." hingespült worden, ich habe diese jedoch - und das kann ich nur nochmal sagen - nicht in einen Editor geladen und daran nach Gutdünken herumeditiert. Punkt.

Prof. Dr. Peter Henning