shutdown restart geht nicht mehr seit Umzug auf PI3 und Jessie

[cotecmania]

Hallo,

bin heute von wheezy/Raspy B umgezogen auf Raspy3B/jessie lite Neuinstallation.
Läuft alles wieder, vor allem schneller, aber der shutdown restart geht nicht mehr.
Danach wird keine FHEMWEB-Seite mehr angezeigt
Wenn ich mit SSH FHEM neu starte (sudo /etc/init.d/fhem start) gehts wieder.
Genauso gehts wieder nach sudo reboot.
nofork habe ich mit 0/1 getestet. Kein Unterschied.

Ideen ?

Gruss
Joe

[rudolfkoenig]

Hast du zufaellig noch ein FHEM-Log-Auszug?
Was ist der Rueckgabewert in FHEM von

Code Auswählen Erweitern

{"$^X $0 $attr{global}{configfile}"}

[Hollo]

Hallo,

bin heute von wheezy/Raspy B umgezogen auf Raspy3B/jessie lite Neuinstallation...

Wenn Du eine saubere Neuinstallation von Jessie gemacht hast, ist "/etc/init.d/..." aber nicht mehr der Standard (Stichworte: systemd / sysvinit).
Wird Dein FHEM dementsprechend gestartet?

[Otto123]

Wenn Du eine saubere Neuinstallation von Jessie gemacht hast, ist "/etc/init.d/..." aber nicht mehr der Standard (Stichworte: systemd / sysvinit).

Moin,

na FHEM richtet bei der Installation trotzdem /etc/init.d/fhem ein.
Ob jetzt systemctl start fhem oder service fhem start - es läuft alles auf ExecStart=/etc/init.d/fhem start hinaus.

Macht das dann wirklich einen Unterschied? Und als Abwärtskompatibel ist init.d doch legitim?

Läuft bei mir zumindest alles ohne Probleme. Lediglich die etwas unklare zeitliche Abhängigkeit vom Netzwerk, klingt mir aber im vorliegenden Fall nicht so.

entweder man macht den Start von fhem vom Netzwerk oder dem ntp Dienst abhängig,
# Den Systemstart von ntp abhängig machen

Code Auswählen Erweitern

sed -i s/'# Required-Start:       $local_fs $remote_fs/# Required-Start:       $local_fs $remote_fs $ntp/' /etc/init.d/fhem
systemctl daemon-reload
oder man fügt am Anfang vom Startscript /etc/init.d/fhem ein "sleep 10" ein.

Gruß Otto

[Hollo]

...
Ob jetzt systemctl start fhem oder service fhem start - es läuft alles auf ExecStart=/etc/init.d/fhem start hinaus.

Macht das dann wirklich einen Unterschied? Und als Abwärtskompatibel ist init.d doch legitim?
...

Daran habe ich gar nicht gedacht, da hast Du recht.

Shutdown restart sollte allerdings auch zum selben Ergebnis wie reboot führen!?

[rudolfkoenig]

Bei shutdown restart startet sich FHEM selbst wieder, beim reboot wird FHEM vom System (init/service/etc) gestartet.
Ich habe auf meine Fragen immer noch keine Antwort.

[cotecmania]

Hi,

Was ist der Rueckgabewert in FHEM von

Code Auswählen Erweitern

{"$^X $0 $attr{global}{configfile}"}

Das hier wird ausgegeben :

Code Auswählen Erweitern

/usr/bin/perl fhem.pl fhem.cfg

FHEM-Log-Auszug eines shutdown restart (FHEM wurde mit SSH neu gestartet) : 

Code Auswählen Erweitern

2016.11.29 21:26:49 0: Server shutdown
Can't use an undefined value as a symbol reference at ./FHEM/51_RPI_GPIO.pm line 418.
2016.11.29 21:26:50 1: BlockingInformParent (BlockingStart): Can't connect to localhost:7072: IO::Socket::INET: connect: Verbindungsaufbau abgelehnt
2016.11.29 21:26:50 1: BlockingInformParent (PRESENCE_ProcessLocalScan): Can't connect to localhost:7072: IO::Socket::INET: connect: Verbindungsaufbau abgelehnt
2016.11.29 21:27:28 2: [MaxScan] UtilsMaxScan_Initialize.68 MaxScan is starting
2016.11.29 21:27:28 1: PERL WARNING: Prototype mismatch: sub main::max ($@) vs ($$) at ./FHEM/99_myUtils.pm line 280.
2016.11.29 21:27:28 1: PERL WARNING: Subroutine max redefined at ./FHEM/99_myUtils.pm line 280.
2016.11.29 21:27:28 1: PERL WARNING: Prototype mismatch: sub main::min ($@) vs ($$) at ./FHEM/99_myUtils.pm line 281.
2016.11.29 21:27:28 1: PERL WARNING: Subroutine min redefined at ./FHEM/99_myUtils.pm line 281.
2016.11.29 21:27:28 1: Including fhem.cfg
2016.11.29 21:27:28 2: eventTypes: loaded 5882 events from ./log/eventTypes.txt
2016.11.29 21:27:29 2: Switched CUL1 rfmode to MAX
2016.11.29 21:27:30 1: HMLAN_Parse: HMLAN1 new condition disconnected
2016.11.29 21:27:30 1: HMLAN_Parse: HMLAN1 new condition init
2016.11.29 21:27:33 2: FB_CALLMONITOR (my_callmonitor) - read 159 contacts from Cache
2016.11.29 21:27:33 0: HourCounter BrennerCounter Define.228 parameters: BrennerCounter HourCounter KM271:Brenner_Ansteuerung:.1.* KM271:Brenner_Ansteuerung:.Kessel.*
2016.11.29 21:27:40 1: Can't open file: TuerKlingel, edge
2016.11.29 21:27:40 1: PERL WARNING: False [] range "\s-" in regex; marked by <-- HERE in m/[\s- <-- HERE :]+/ at ./FHEM/69_LevelJET.pm line 197, <$fh> line 2065.
2016.11.29 21:27:40 1: LevelJET->*** Funktion Initialize ***
2016.11.29 21:27:40 1: LevelJET MyLevelJET->*** Funktion define ***
2016.11.29 21:27:40 1: Including ./log/fhem.save
2016.11.29 21:27:40 1: Can't open file: TuerKlingel, value
2016.11.29 21:27:40 1: PERL WARNING: Use of uninitialized value $val in string eq at ./FHEM/51_RPI_GPIO.pm line 272, <$fh> line 1841.
2016.11.29 21:27:41 0: Featurelevel: 5.7
2016.11.29 21:27:41 0: Server started with 298 defined entities (fhem.pl:12680/2016-11-28 perl:5.020002 os:linux user:fhem pid:11805)

Gruss
Joe

[Otto123]

Shutdown restart sollte allerdings auch zum selben Ergebnis wie reboot führen!?

Shutdown restart startet ausschließlich FHEM neu. Alle anderen Dienste bleiben am laufen.
Bei reboot starten alle Dienste neu, das System wird komplett initialisiert.

Da ist ne ganz andere Nummer 

[cotecmania]

@Rudolf

Kannst Du mit meiner Antwort was anfangen ?

Gruss

[rudolfkoenig]

Kannst Du mit meiner Antwort was anfangen ?

Nicht wirklich (leider), liegt aber an dem Inhalt, nicht an Dir.

"restart" findet wohl nicht statt, weil zw. Shutdown und Startup 38sek vergehen.
Log ist merkwuerdig, weil hier evtl. Fehlermeldungen vom Neustart auftauchen muessten.
Hast du sicher shutdown restart gemacht, und nicht nur shutdown?

Wo liegt fhem.pl und wo liegen die Module (FHEM Unterverzeichnis)? Falls beide in unterschiedlichen Verzeichnissen liegen, dann sind folgende Fragen relevant:
Hast du zwischen FHEM-Start und "shutdown restart" ein FHEM-update gemacht?
Hast du Module, die nicht im "offiziellen" FHEM sind, und "chdir" ausfuehren?
Oder eigenen Code mir chdir?
Falls ein Modul mit "chdir" in ein anderes Verzeichnis wechselt, dann funktioniert restart nicht.

Ich wuerde in fhem.cfg temporaer "attr global logfile -" stellen, fhem in einem Terminal-Fenster starten, und "shutdown restart" ausloesen, in der Hoffnung, dass in dem Fenster mehr/verstaendliche Meldungen kommen.

[Hollo]

Shutdown restart startet ausschließlich FHEM neu. Alle anderen Dienste bleiben am laufen.
Bei reboot starten alle Dienste neu, das System wird komplett initialisiert.

Da ist ne ganz andere Nummer 

Ach Mist, ich war ganz woanders unterwegs...
Da hier so einige bei jeder Kleinigkeit das ganze System neustarten, war ich davon ausgegangen, dass in beiden Fällen vom Linux die Rede war.
An das "shutdown & restart" von FHEM habe ich gar nicht gedacht.   

[MrPerfect]

Hallo, wie ist es ausgegangen?
Ich habe das gleiche Problem. Die letzte Meldung im Log nach shutdown restart lautet:

Can't use an undefined value as a symbol reference at ./FHEM/51_RPI_GPIO.pm line 418

Danach hilft nur noch ein sudo service fhem restart

[Martin Quinke]

Hab das gleiche Problem:

Code Auswählen Erweitern


2017.03.25 20:39:22 0: Server shutdown
Can't use an undefined value as a symbol reference at ./FHEM/51_RPI_GPIO.pm line 418.
2017.03.25 20:39:26 1: BlockingInformParent (BlockingStart): Can't connect to localhost:7072: IO::Socket::INET: connect: Verbindungsaufbau abgelehnt
2017.03.25 20:39:26 1: BlockingInformParent (PRESENCE_ProcessLocalScan): Can't connect to localhost:7072: IO::Socket::INET: connect: Verbindungsaufbau abgelehnt


Danach kommt nichts mehr.

Gibt es eine Lösung?

[finndus]

Hallo,
auch ich habe das gleiche Problem.
Das Logfile mit verbose 5:

Code Auswählen Erweitern

2017.10.26 20:31:26 5: Cmd: >shutdown restart<
2017.10.26 20:31:26 5: Starting notify loop for global, 1 event(s), first is SHUTDOWN
2017.10.26 20:31:26 5: createNotifyHash
2017.10.26 20:31:26 5: End notify loop for global
2017.10.26 20:31:26 0: Server shutdown
2017.10.26 20:31:26 5: SW: X00
Can't use an undefined value as a symbol reference at ./FHEM/51_RPI_GPIO.pm line 418.

FHEM läuft auf einem RPI2 mit Raspbian 8.0 (jessie).

Verschluckt es sich irgendwie an der GPIO Konfiguration?

[finndus]

Konnte mittlerweile das Problem lösen:
Hatte noch einen GPIO Pin definiert aber in jessie nicht aktiviert. Beim Versuch das Gerät zu löschen stürzte fhem auch immer ab. Manuelles löschen in der fhem.cfg brachte Erfolg.