FHEM startet nicht neu nach "shutdown restart"

Begonnen von zweiundzwanzig, 21 Dezember 2017, 13:28:52

Vorheriges Thema - Nächstes Thema

zweiundzwanzig

Hi,
ich habe fhem auf einer VMware mit Ubuntu laufen. Schon seit langem ist es so, dass ich nach einem "shutdown restart" zwar fhem abschalte, es dann aber nicht von selber wieder startet. Ich muss mich dann über ssh auf dem Server einloggen und fhem durch "sudo /etc/init.d/fhem start" neu starten. Ich hatte bisher keine Lust mich darum zu kümmern aber es nervt schon sehr, gerade wenn ich nicht an meinem eigenen Rechner bin. Wie könnte ich das Problem einkreisen und ggf. beheben?

LG 22
2x MAX CuBe mit a-culf im Moritzbetrieb
1x MAX CuBe mit a-culf im Homematicbetrieb
60x MAX Heizkörperthermostat plus | 2x HM Schaltaktoren | 1x MAX Wandthermostat
1x FHEM Ubuntu Server auf VMWare
24 Räume, die durch ical Kalender geheizt werden

Beta-User

Sowas ähnliches wurde hier neulich berichtet. (Es scheint aber auch dort keine wirkliche Lösung gefunden worden zu sein...)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Wernieman

- 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

zweiundzwanzig

Ubuntu 16.04.3 LTS

ein "cat /proc/1/comm" erzeugt: systemd
Das ist das wohl das Problem oder? Ich kenne mich da leider nicht gut aus.
Wurde das startsystem bei Ubuntu umgestellt? Kannst du mir helfen/ mir zwei drei Stichworte sagen um das umzubauen?
2x MAX CuBe mit a-culf im Moritzbetrieb
1x MAX CuBe mit a-culf im Homematicbetrieb
60x MAX Heizkörperthermostat plus | 2x HM Schaltaktoren | 1x MAX Wandthermostat
1x FHEM Ubuntu Server auf VMWare
24 Räume, die durch ical Kalender geheizt werden

herrmannj

Zitat von: Beta-User am 21 Dezember 2017, 13:34:52
Sowas ähnliches wurde hier neulich berichtet. (Es scheint aber auch dort keine wirkliche Lösung gefunden worden zu sein...)
Yepp. Da ist ein modul fehlerhaft und muss repariert werden.

Daher: nicht raten, log posten!

Außerdem fhem über die console mit -d starten und dort shutdown. Dann Fehlermeldungen suchen.

zweiundzwanzig

das Log sieht so aus: (um 13:57 habe ich "shutdown restart" geamcht und um 14:17 per "sudo /etc/init.d/fhem start" fhem neu gestartet.

2017.12.21 13:57:11 0: Server shutdown
2017.12.21 13:57:13 1: Including fhem.cfg
2017.12.21 13:57:13 1: telnetPort: Can't open server port at 7072: Address already in use. Exiting.
2017.12.21 14:17:24 1: Including fhem.cfg
2017.12.21 14:17:24 3: telnetPort: port 7072 opened
2017.12.21 14:17:24 3: WEB: port 8083 opened
2017.12.21 14:17:24 3: WEBphone: port 8084 opened
2017.12.21 14:17:24 3: WEBtablet: port 8085 opened
2017.12.21 14:17:25 2: eventTypes: loaded 3984 events from ./log/eventTypes.txt
2017.12.21 14:17:25 3: Opening CUBe_1 device 192.168.100.205:2323
2017.12.21 14:17:25 3: CUBe_1: Possible commands: BbCFiAZNEkGMKLUYRTVWXefltxz
2017.12.21 14:17:25 3: CUBe_1 device opened
2017.12.21 14:17:25 2: Switched CUBe_1 rfmode to MAX
2017.12.21 14:17:25 3: CUL_MAX_Check: Detected firmware version 154 of the CUL-compatible IODev
2017.12.21 14:17:26 3: Opening CUBe_3 device 192.168.100.204:2323
2017.12.21 14:17:27 3: CUBe_3: Possible commands: BbCFiAZNEkGMKLUYRTVWXefltxz
2017.12.21 14:17:27 3: CUBe_3 device opened
2017.12.21 14:17:27 2: Switched CUBe_3 rfmode to MAX
2017.12.21 14:17:27 3: CUL_MAX_Check: Detected firmware version 154 of the CUL-compatible IODev
2017.12.21 14:17:28 3: WetterHeckinghausen: Defined with URL https://api.wunderground.com/weatherstation/WXCurrentObXML.asp?ID=IWUPPERT58 and interval 600
2017.12.21 14:17:28 1: Including ./log/fhem.save
2017.12.21 14:17:28 3: monitoring (Activity_monitoring) set Activity_monitoring active
2017.12.21 14:17:28 3: monitoring (Batterie_Monitor) set Batterie_Monitor active
2017.12.21 14:17:28 3: monitoring (Batterie_monitoring) set Batterie_monitoring active
2017.12.21 14:17:28 0: Featurelevel: 5.8
2017.12.21 14:17:28 0: Server started with 228 defined entities (fhem.pl:15657/2017-12-20 perl:5.022001 os:linux user:cgw pid:9174)
2x MAX CuBe mit a-culf im Moritzbetrieb
1x MAX CuBe mit a-culf im Homematicbetrieb
60x MAX Heizkörperthermostat plus | 2x HM Schaltaktoren | 1x MAX Wandthermostat
1x FHEM Ubuntu Server auf VMWare
24 Räume, die durch ical Kalender geheizt werden

Beta-User

Das sieht aber doch nach einem versuchten Neustart aus (including...)?
Da läuft scheinbar noch was anderes, wass sich dann den telnet-port krallt. FHEM müßte den ja eigentlich wieder freigegeben haben.

War das deconz (?), das denselben port wollte?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

zweiundzwanzig

Wenn ich nach dem "shutdown restart" ein "sudo netstat -nlp|grep 7072" mache kriege ich KEIN Ergebnis obwohl im Log ja steht, dass der POrt belegt sei.
Nach meinem sudo /etc/init.d/fhem start kriege ich mit "sudo netstat -nlp|grep 7072" ein:
tcp        0      0 0.0.0.0:7072            0.0.0.0:*               LISTEN      9285/perl       

Versucht Fhem evtl zu schnell neu zu starten bevor der Port frei ist?
2x MAX CuBe mit a-culf im Moritzbetrieb
1x MAX CuBe mit a-culf im Homematicbetrieb
60x MAX Heizkörperthermostat plus | 2x HM Schaltaktoren | 1x MAX Wandthermostat
1x FHEM Ubuntu Server auf VMWare
24 Räume, die durch ical Kalender geheizt werden

Frank_Huber

Will er evtl fhem zu schnell wieder neu starten?

Mit dem Handy online, daher kurz gefasst...


Beta-User

...Gedenksekunden in's init.d-script einbauen, dann sehen wir es...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

RaspiLED

#10
Zeig mal
find /etc/. | grep fhem
Bei mir:

/etc/./rc0.d/K01fhem
/etc/./systemd/system/fhem.service
/etc/./systemd/system/multi-user.target.wants/fhem.service
find: '/etc/./polkit-1/localauthority'/etc/./rc2.d/S01fhem
: Keine Berechtigung
/etc/./rc6.d/K01fhem
/etc/./rc4.d/S01fhem
/etc/./rc3.d/S01fhem
find: '/etc/./ssl/private': Keine Berechtigung
find: '/etc/./cups/ssl': Keine Berechtigung
/etc/./rc5.d/S01fhem
/etc/./init.d/fhem
/etc/./rc1.d/K01fhem

Und dann bitte den Inhalt von
/etc/init.d/fhem
Insbesondere ist spannend was nach Required-Start steht (z.B. $network)

Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Raspberry Pi mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, WifiLight2, Bravia, ...

Morgennebel

Einziger Spender an FHEM e.V. mit Dauerauftrag seit >= 24 Monaten

FHEM: MacMini/ESXi, 2-3 FHEM Instanzen produktiv
In-Use: STELLMOTOR, VALVES, PWM-PWMR, Xiaomi, Allergy, Proplanta, UWZ, MQTT,  Homematic, Luftsensor.info, ESP8266, ESERA

zweiundzwanzig

#12
find /etc/. | grep fhem
find: "/etc/./polkit-1/localauthority": Keine Berechtigung
find: "/etc/./ssl/private": Keine Berechtigung
find: /etc/./rc2.d/S01fhem
"/etc/./cups/ssl": Keine Berechtigung
/etc/./rc4.d/S01fhem
/etc/./rc1.d/K01fhem
/etc/./init.d/fhem
/etc/./rc6.d/K01fhem
/etc/./rc5.d/S01fhem
/etc/./rc0.d/K01fhem
/etc/./rc3.d/S01fhem[/td]

in /etc/init.d/fhem:
#!/bin/sh
# description: Start or stop the fhem server
# Added by Alex Peuchert

### BEGIN INIT INFO
# Provides:             fhem.pl
# Required-Start:       $local_fs $remote_fs
# Required-Stop:        $local_fs $remote_fs
# Default-Start:        2 3 4 5
# Default-Stop:         0 1 6
# Short-Description:    FHEM server
### END INIT INFO

set -e
cd /opt/fhem
port=7072

if test "$2" != "noaptmark"; then
  apt-mark hold fhem > /dev/null
fi

case "$1" in
'start')

        echo "Starting fhem..."

# if you need to start hmland for use with
# Homematic, please start the hmland daemon
# like this (please use correct path and port,
# depending on your installation!)
#
#       /opt/hmcfgusb/hmland -d -p 1234 -r 0
#

        perl fhem.pl fhem.cfg

# if you want to use configDB for configuration,
# use this command to start fhem:
#
#       perl fhem.pl configDB
#
# and remove/comment the above line including fhem.cfg

        RETVAL=$?
        ;;
'stop')
        echo "Stopping fhem..."

# if you want to stop hmland during fhem stop:
#       pkill hmland

        pkill -U fhem perl
        RETVAL=$?
        ;;
'status')
        cnt=`ps -ef | grep "fhem.pl" | grep -v grep | wc -l`
        if [ "$cnt" -eq "0" ] ; then
                echo "fhem is not running"
        else
                echo "fhem is running"
        fi
        ;;
*)
        echo "Usage: $0 { start | stop | status }"
        RETVAL=1
        ;;
esac
exit $RETVAL


Was macht denn Fhem eigentlich bei "shutdown restart"? Macht es einfach ein " /etc/init.d/fhem stop && /etc/init.d/fhem start" ?

Wie könnte ich sinnvoll eine Pause einbauen?
2x MAX CuBe mit a-culf im Moritzbetrieb
1x MAX CuBe mit a-culf im Homematicbetrieb
60x MAX Heizkörperthermostat plus | 2x HM Schaltaktoren | 1x MAX Wandthermostat
1x FHEM Ubuntu Server auf VMWare
24 Räume, die durch ical Kalender geheizt werden

zweiundzwanzig

Hab gerade herausgefunden, dass wenn ich nach dem gescheiterten "shutdown restart" ein "sudo /etc/init.d/fhem status" mach Fhem anscheinend noch (oder schon wieder) läuft: "fhem is running".

Jemand eine schlaue Idee?
2x MAX CuBe mit a-culf im Moritzbetrieb
1x MAX CuBe mit a-culf im Homematicbetrieb
60x MAX Heizkörperthermostat plus | 2x HM Schaltaktoren | 1x MAX Wandthermostat
1x FHEM Ubuntu Server auf VMWare
24 Räume, die durch ical Kalender geheizt werden

RaspiLED

Hi,
wird hier auch gerade diskutiert:
Zitat von: Otto123 am 23 Dezember 2017, 11:23:24
Dieser Befehl macht das für Dich. Richtige Datei, richtige Stelle. Vorher bitte sudo su
sed -i s/'        perl fhem.pl fhem.cfg/        sleep 60\n        perl fhem.pl fhem.cfg/' /etc/init.d/fhem

Die Beschreibung von sed und die Erklärung vom Syntax solltest Du durch google finden.  ;)

Du kannst auch die Abhängigkeit eintragen
# Den Systemstart von ntp abhängig machen
sed -i s/'# Required-Start:       $local_fs $remote_fs/# Required-Start:       $local_fs $remote_fs $ntp/' /etc/init.d/fhem
systemctl daemon-reload

Das # im init Script ist nicht auskommentiert, das ist so!

Aber wie gesagt, das wird für Deinen Fall nichts bringen. Selbst wenn das Netzwerk gestartet ist, ist dein Laufwerk noch nicht verbunden!

Gruß Otto

Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Raspberry Pi mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, WifiLight2, Bravia, ...

zweiundzwanzig

Danke! Eine 20 Sekunden Verzögerung nach oben angegebenem Beispiel am Anfang des "start" scripts klappt für mich! Jetzt funktioniert der Restart wieder! Danke!

2x MAX CuBe mit a-culf im Moritzbetrieb
1x MAX CuBe mit a-culf im Homematicbetrieb
60x MAX Heizkörperthermostat plus | 2x HM Schaltaktoren | 1x MAX Wandthermostat
1x FHEM Ubuntu Server auf VMWare
24 Räume, die durch ical Kalender geheizt werden