Ich hatte den Fehler vor einiger Zeit schon mal https://forum.fhem.de/index.php/topic,93972.0.html und nun ist er wieder da:
Ich habe heute einen restart von FHEM durchgeführt und dann festgestellt, dass ich nicht mehr auf die Weboberfläche zugreifen kann. Bei einer Telnet Verbindung passiert folgendes:
pi@pi-fhem:~ $ telnet 127.0.0.1 7072
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
Allerdings wird weder bei "info timer" noch bei "version" etwas ausgespuckt. Laut Systemd läuft fhem:
pi@pi-fhem:~ $ sudo systemctl status fhem -l
● fhem.service - FHEM Home Automation
Loaded: loaded (/etc/systemd/system/fhem.service; enabled)
Active: active (running) since Thu 2019-01-10 22:50:13 CET; 4min 43s ago
Process: 3206 ExecStop=/etc/init.d/fhem stop (code=exited, status=1/FAILURE)
Process: 3221 ExecStart=/etc/init.d/fhem start (code=exited, status=0/SUCCESS)
Main PID: 3230 (perl)
CGroup: /system.slice/fhem.service
└─3230 perl fhem.pl configDB
Jan 10 22:50:12 pi-fhem systemd[1]: fhem.service holdoff time over, scheduling restart.
Jan 10 22:50:12 pi-fhem systemd[1]: Stopping FHEM Home Automation...
Jan 10 22:50:12 pi-fhem systemd[1]: Starting FHEM Home Automation...
Jan 10 22:50:12 pi-fhem fhem[3221]: Starting fhem...
Jan 10 22:50:13 pi-fhem systemd[1]: Started FHEM Home Automation.
Wenn ich mittels configdb auf die Version 15 zurück gehe, dann läuft alles wieder. Ein Anzeigen der Unterschiede zwischen den Versionen gibt wirft folgende Info aus:
compare device: all in current version 0 (left) to version: UNSAVED (right)
+-----+-----------------------------------------------------------------------------------------------+-----+-----------------------------------------------------------------------------------------------+
| 1109|attr global logfile ./log/fhem-%Y-%m.log | 1109|attr global logfile ./log/fhem-%Y-%m.log |
| 1110|attr global longitude 8.7252843 | 1110|attr global longitude 8.7252843 |
| 1111|attr global modpath . | 1111|attr global modpath . |
* 1112|attr global motd SecurityCheck: * 1112|attr global motd Messages collected while initializing FHEM: *
* 1113| WEB is not password protected * 1113|configDB: Please define web first *
* 1114| telnetPort is not password protected * | |
* 1115| WEBUser is not password protected * | |
| 1116| | 1114| |
* 1117|Protect this FHEM installation by configuring the allowed device allowedWEBUser * 1115|Autosave deactivated *
* 1118|You can disable this message with attr global motd none * | |
| 1119|attr global nrarchive 2 | 1116|attr global nrarchive 2 |
| 1120|attr global pidfilename /var/run/fhem/fhem.pid | 1117|attr global pidfilename /var/run/fhem/fhem.pid |
| 1121|attr global sendStatistics onUpdate | 1118|attr global sendStatistics onUpdate |
+-----+-----------------------------------------------------------------------------------------------+-----+-----------------------------------------------------------------------------------------------+
| 3397|attr WR.Tablet_AMAD remoteServer Automagic | 3394|attr WR.Tablet_AMAD remoteServer Automagic |
| 3398|attr WR.Tablet_AMAD room Z_R\xc3\xa4ume->Wohnraum | 3395|attr WR.Tablet_AMAD room Z_R\xc3\xa4ume->Wohnraum |
| 3399|attr configdb private 1 | 3396|attr configdb private 1 |
* 3400|#created Tue Dec 11 21:20:48 2018 * 3397|#created Thu Jan 10 22:57:40 2019 *
+-----+-----------------------------------------------------------------------------------------------+-----+-----------------------------------------------------------------------------------------------+
Weiterhin sind alle Readings in der Revocer Version Nr. 15 weg, welche nicht jetzt automatisch durch den Neustart angelegt wurden. Ist das immer so bei rescuemode? Und kann ich die irgendwie wieder bekommen?
Ich habe kein Plan was falsch läuft beim Start. Im Logfile steht in der letzten Zeile bei jedem Start mit einer Version, die nicht geht als letztes:
2019.01.10 22:57:07 3: IPKamera_status: Defined with URL http://xxxx:xx/cgi-bin/CGIProxy.fcgi?cmd=getDevState&usr=xxx&pwd=xxx and interval 5
Hat jemand eine Idee woran es liegen könnte?
Und noch eine Frage. Kann ich mir quasi den Unterschied zwischen Version 0 und 1 anzeigen lassen? Dann würde ich sehen was ich alles wieder manuell ändern muss bzw wo vielleicht der Fehler liegt. Weil mit "configdb diff all current" wird mir ja nicht der Unterscheid zu Version 1 angezeigt. Und dies bräuchte ich um mir mal den Fehler zeigen zu lassen. Ich laufe mit 0 ja gerade eigentlich auf Version 15 weil ich diese recovern musste. Wenn ich 1 recovere dann komme ich ja gar nicht auf FHEMWEB.
Zu configDB Spezialitaeten kann ich nichts sagen, die fehlende Reaktion wuerde ich mit "perl fhem.pl -d configDB" lokalisieren.
Hier bleibt der Prozess hängen:
2019.01.11 10:19:11 5: Loading ./FHEM/98_Verkehrsinfo.pm
2019.01.11 10:19:12 5: Cmd: >attr Verkehrsinfo disable 0<
Folgende Version von Verkehrsinfo habe ich:
# $Id: 98_Verkehrsinfo.pm 17616 2018-10-24 21:57:44Z martins $
und laut der PM ist disable auch eingebaut. Liegt hier vielleicht ein Fehler in der PM vor, dass FHEM sich aufhängt?
Also es hat defintiv mit
2019.01.11 10:19:12 5: Cmd: >attr Verkehrsinfo disable 0<
zutun. Ich habe habe die Datenbank Datei mal geöffnet und alle Einträge mit Verkehrsinfo disable 0 gelöscht. Daraufhin konnte ich ohne Probleme Fhem starten und durchlaufen lassen. Egal welche Recover Version ich genutzt habe.
Bei "disable 0" wird Verkehrsinfo_GetUpdate ausgefuehrt, der InternalTimer mit 1 als vierten (optionalen) Parameter aufruft.
Vermutlich hat der Autor nicht nachgeschaut, wozu das gut ist: InternalTimer wartet damit die angegebene Zeit blockierend ab, wenn FHEM noch nicht initialisiert ist.
Wuesste gerne, wo diese Zeile herkopiert wurde, da ist es vermutlich auch falsch.
Zitat von: rudolfkoenig am 11 Januar 2019, 11:09:05
Bei "disable 0" wird Verkehrsinfo_GetUpdate ausgefuehrt, der InternalTimer mit 1 als vierten (optionalen) Parameter aufruft.
Vermutlich hat der Autor nicht nachgeschaut, wozu das gut ist: InternalTimer wartet damit die angegebene Zeit blockierend ab, wenn FHEM noch nicht initialisiert ist.
Wuesste gerne, wo diese Zeile herkopiert wurde, da ist es vermutlich auch falsch.
Bis vor drei Jahren war diese 1 als letzter Parameter Gang und gebe. Alte Module haben das glaube sogar noch. Ich hatte bis vor 2 Jahren auch noch 2 Module mit sowas.
Grüße
Habe Martins mal eine PM geschickt.
Und danke für die Hilfe bei der Fehlersuche :)
hab die Änderung vorgenommen und den Parameter auf 0 gesetzt und die neue Version ist eingecheckt.
Gleich auch noch einen anderen bug in Zusammenhang mit dem Attribut disable behoben.
Ich kann mich dunkel erinnern, das ich lange überlegt habe ob ich den Parameter auf 1 oder 0 setzte, warum die Entscheidung auf 1 gefallen ist trotz Recherche, kann ich leider nicht mehr sagen ... :-\
Danke :)