Hallo,
ich habe ein update gefahren und seit den komische Probleme.
Fhem starte ca. alle 2 min neu.
Im Log steht server shutdown, dann kommt ein normaler Neustart.
Kein Fehler nichts im Log.
Viele Grüße
Stefan
Wollte eigentlich nur "Na das ist ja mal was! Viele Grüße zurück!" schreiben, denn eine konkrete Frage scheinst Du ja nicht zu haben... Aber naja :)
Dafür fallen mir ein paar ein:
Was für Komponenten hat das System?
Wo ist eine Logdatei zum anschauen?
Welche verbose-Levels werden bei den Komponenten gefahren?
Etwas mehr Infos, bitte.
Hallo,
hier ein paar Infos:
- Fhem aktuelle Version
- Homatic
- Mysensors
- FS20
alles zusammen ca. 50 Sensoren / Aktoren
Am Samstag wollte ich die Datenbank reduzieren. Ging leider nicht, also erstmal ein update gefahren.
Ab da läuft das Fhem wie ein Sack Muscheln.
Im Anhang das Log. Es wiederholt sich so im 2 Minuten Takt
Viele Grüße
Stefan
Hast Du ein watchog konfiguriert. Also auf Betriebssystem Ebene. Nicht in FHEM.
Zeig bitte ein komplettes Log vom Start bis zum nächsten nicht gewollten neustart.
Hallo,
ich habe was im Systemlog von Linux entdeckt
Aug 7 17:52:34 M60 systemd[1]: fhem.service: Service hold-off time over, scheduling restart.
Aug 7 17:52:34 M60 systemd[1]: Stopped FHEM Home Automation.
Aug 7 17:52:34 M60 systemd[1]: Starting FHEM Home Automation...
Aug 7 17:54:04 M60 systemd[1]: fhem.service: Start operation timed out. Terminating.
Aug 7 17:54:07 M60 systemd[1]: Failed to start FHEM Home Automation.
Aug 7 17:54:07 M60 systemd[1]: fhem.service: Unit entered failed state.
Aug 7 17:54:07 M60 systemd[1]: fhem.service: Failed with result 'timeout'.
Aug 7 17:54:08 M60 systemd[1]: fhem.service: Service hold-off time over, scheduling restart.
Aug 7 17:54:08 M60 systemd[1]: Stopped FHEM Home Automation.
Aug 7 17:54:08 M60 systemd[1]: Starting FHEM Home Automation...
Aug 7 17:55:38 M60 systemd[1]: fhem.service: Start operation timed out. Terminating.
Aug 7 17:55:41 M60 systemd[1]: Failed to start FHEM Home Automation.
Aug 7 17:55:41 M60 systemd[1]: fhem.service: Unit entered failed state.
Aug 7 17:55:41 M60 systemd[1]: fhem.service: Failed with result 'timeout'.
Aug 7 17:55:41 M60 systemd[1]: fhem.service: Service hold-off time over, scheduling restart.
Aug 7 17:55:41 M60 systemd[1]: Stopped FHEM Home Automation.
Aug 7 17:55:41 M60 systemd[1]: Starting FHEM Home Automation...
Sehe ich das richtig das der Dienst immer wieder neu gestartet wird.
Viele Grüße
Stefan
Hallo,
und das ist das Ergebnis von systemctl status fhem.service, das ist eine Endloschleife, Neustart alle 1,5 Min
● fhem.service - FHEM Home Automation
Loaded: loaded (/etc/systemd/system/fhem.service; enabled; vendor preset: enabled)
Active: activating (start) since Tue 2018-08-07 18:05:04 CEST; 1min 29s ago
Cntrl PID: 3557 (perl)
Tasks: 4 (limit: 4915)
CGroup: /system.slice/fhem.service
├─3557 /usr/bin/perl fhem.pl fhem.cfg
├─3582 /usr/bin/perl fhem.pl fhem.cfg
├─3583 /usr/bin/perl fhem.pl fhem.cfg
└─3584 /usr/bin/perl fhem.pl fhem.cfg
Aug 07 18:05:04 M60 systemd[1]: Starting FHEM Home Automation...
root@M60:/opt/fhem/log# systemctl status fhem.service
● fhem.service - FHEM Home Automation
Loaded: loaded (/etc/systemd/system/fhem.service; enabled; vendor preset: enabled)
Active: deactivating (final-sigterm) (Result: timeout)
Cntrl PID: 3557 (perl)
Tasks: 3 (limit: 4915)
CGroup: /system.slice/fhem.service
├─3557 /usr/bin/perl fhem.pl fhem.cfg
├─3583 /usr/bin/perl fhem.pl fhem.cfg
└─3584 /usr/bin/perl fhem.pl fhem.cfg
Aug 07 18:05:04 M60 systemd[1]: Starting FHEM Home Automation...
Aug 07 18:06:34 M60 systemd[1]: fhem.service: Start operation timed out. Terminating.
root@M60:/opt/fhem/log# systemctl status fhem.service
● fhem.service - FHEM Home Automation
Loaded: loaded (/etc/systemd/system/fhem.service; enabled; vendor preset: enabled)
Active: activating (start) since Tue 2018-08-07 18:06:38 CEST; 2s ago
Cntrl PID: 3677 (perl)
Tasks: 1 (limit: 4915)
CGroup: /system.slice/fhem.service
└─3677 /usr/bin/perl fhem.pl fhem.cfg
Aug 07 18:06:38 M60 systemd[1]: Starting FHEM Home Automation...
root@M60:/opt/fhem/log# systemctl status fhem.service
● fhem.service - FHEM Home Automation
Loaded: loaded (/etc/systemd/system/fhem.service; enabled; vendor preset: enabled)
Active: activating (start) since Tue 2018-08-07 18:06:38 CEST; 5s ago
Cntrl PID: 3677 (perl)
Tasks: 1 (limit: 4915)
CGroup: /system.slice/fhem.service
└─3677 /usr/bin/perl fhem.pl fhem.cfg
Aug 07 18:06:38 M60 systemd[1]: Starting FHEM Home Automation...
root@M60:/opt/fhem/log# systemctl status fhem.service
● fhem.service - FHEM Home Automation
Loaded: loaded (/etc/systemd/system/fhem.service; enabled; vendor preset: enabled)
Active: activating (start) since Tue 2018-08-07 18:06:38 CEST; 9s ago
Cntrl PID: 3677 (perl)
Tasks: 1 (limit: 4915)
CGroup: /system.slice/fhem.service
└─3677 /usr/bin/perl fhem.pl fhem.cfg
Aug 07 18:06:38 M60 systemd[1]: Starting FHEM Home Automation...
root@M60:/opt/fhem/log# systemctl status fhem.service
● fhem.service - FHEM Home Automation
Loaded: loaded (/etc/systemd/system/fhem.service; enabled; vendor preset: enabled)
Active: activating (start) since Tue 2018-08-07 18:06:38 CEST; 10s ago
Cntrl PID: 3677 (perl)
Tasks: 1 (limit: 4915)
CGroup: /system.slice/fhem.service
└─3677 /usr/bin/perl fhem.pl fhem.cfg
Aug 07 18:06:38 M60 systemd[1]: Starting FHEM Home Automation...
root@M60:/opt/fhem/log# systemctl status fhem.service
● fhem.service - FHEM Home Automation
Loaded: loaded (/etc/systemd/system/fhem.service; enabled; vendor preset: enabled)
Active: activating (start) since Tue 2018-08-07 18:06:38 CEST; 10s ago
Cntrl PID: 3677 (perl)
Tasks: 1 (limit: 4915)
CGroup: /system.slice/fhem.service
└─3677 /usr/bin/perl fhem.pl fhem.cfg
Aug 07 18:06:38 M60 systemd[1]: Starting FHEM Home Automation...
root@M60:/opt/fhem/log# systemctl status fhem.service
● fhem.service - FHEM Home Automation
Loaded: loaded (/etc/systemd/system/fhem.service; enabled; vendor preset: enabled)
Active: activating (start) since Tue 2018-08-07 18:06:38 CEST; 11s ago
Cntrl PID: 3677 (perl)
Tasks: 1 (limit: 4915)
CGroup: /system.slice/fhem.service
└─3677 /usr/bin/perl fhem.pl fhem.cfg
Aug 07 18:06:38 M60 systemd[1]: Starting FHEM Home Automation...
root@M60:/opt/fhem/log# systemctl status fhem.service
● fhem.service - FHEM Home Automation
Loaded: loaded (/etc/systemd/system/fhem.service; enabled; vendor preset: enabled)
Active: activating (start) since Tue 2018-08-07 18:06:38 CEST; 12s ago
Cntrl PID: 3677 (perl)
Tasks: 1 (limit: 4915)
CGroup: /system.slice/fhem.service
└─3677 /usr/bin/perl fhem.pl fhem.cfg
Aug 07 18:06:38 M60 systemd[1]: Starting FHEM Home Automation...
root@M60:/opt/fhem/log# systemctl status fhem.service
● fhem.service - FHEM Home Automation
Loaded: loaded (/etc/systemd/system/fhem.service; enabled; vendor preset: enabled)
Active: activating (start) since Tue 2018-08-07 18:06:38 CEST; 12s ago
Cntrl PID: 3677 (perl)
Tasks: 1 (limit: 4915)
CGroup: /system.slice/fhem.service
└─3677 /usr/bin/perl fhem.pl fhem.cfg
Aug 07 18:06:38 M60 systemd[1]: Starting FHEM Home Automation...
root@M60:/opt/fhem/log# systemctl status fhem.service
● fhem.service - FHEM Home Automation
Loaded: loaded (/etc/systemd/system/fhem.service; enabled; vendor preset: enabled)
Active: activating (start) since Tue 2018-08-07 18:06:38 CEST; 13s ago
Cntrl PID: 3677 (perl)
Tasks: 1 (limit: 4915)
CGroup: /system.slice/fhem.service
└─3677 /usr/bin/perl fhem.pl fhem.cfg
Aug 07 18:06:38 M60 systemd[1]: Starting FHEM Home Automation...
root@M60:/opt/fhem/log# systemctl status fhem.service
● fhem.service - FHEM Home Automation
Loaded: loaded (/etc/systemd/system/fhem.service; enabled; vendor preset: enabled)
Active: activating (start) since Tue 2018-08-07 18:06:38 CEST; 14s ago
Cntrl PID: 3677 (perl)
Tasks: 2 (limit: 4915)
CGroup: /system.slice/fhem.service
├─3677 /usr/bin/perl fhem.pl fhem.cfg
└─3720 /usr/bin/perl fhem.pl fhem.cfg
Aug 07 18:06:38 M60 systemd[1]: Starting FHEM Home Automation...
root@M60:/opt/fhem/log# systemctl status fhem.service
● fhem.service - FHEM Home Automation
Loaded: loaded (/etc/systemd/system/fhem.service; enabled; vendor preset: enabled)
Active: activating (start) since Tue 2018-08-07 18:06:38 CEST; 14s ago
Cntrl PID: 3677 (perl)
Tasks: 4 (limit: 4915)
CGroup: /system.slice/fhem.service
├─3677 /usr/bin/perl fhem.pl fhem.cfg
├─3720 /usr/bin/perl fhem.pl fhem.cfg
├─3723 /usr/bin/perl fhem.pl fhem.cfg
└─3724 /usr/bin/perl fhem.pl fhem.cfg
Aug 07 18:06:38 M60 systemd[1]: Starting FHEM Home Automation...
Grüße
Hallo,
und hier das Log mit einer fast leeren fhem.cfg.
018.08.07 18:32:06 3: WEBremote: port 8084 opened
2018.08.07 18:32:06 3: WEBtablet: port 8085 opened
2018.08.07 18:32:06 1: Including ./log/fhem.save
2018.08.07 18:32:06 1: Including fhem.cfg
2018.08.07 18:32:06 3: telnetPort: port 7072 opened
2018.08.07 18:32:06 3: WEB: port 8083 opened
2018.08.07 18:32:06 3: WEB_ext: port 8086 opened
2018.08.07 18:32:06 3: WEBremote: port 8084 opened
2018.08.07 18:32:06 3: WEBtablet: port 8085 opened
2018.08.07 18:32:06 1: Including ./log/fhem.save
2018.08.07 18:33:08 0: Server shutdown
2018.08.07 18:33:09 1: PERL WARNING: "my" variable $Device masks earlier declaration in same scope at ./FHEM/99_myUtils.pm line 58.
2018.08.07 18:33:09 1: PERL WARNING: "my" variable $Sensor masks earlier declaration in same scope at ./FHEM/99_myUtils.pm line 59.
2018.08.07 18:33:09 1: Including fhem.cfg
2018.08.07 18:33:09 3: telnetPort: port 7072 opened
2018.08.07 18:33:09 3: WEB: port 8083 opened
2018.08.07 18:33:09 3: WEB_ext: port 8086 opened
2018.08.07 18:33:09 3: WEBremote: port 8084 opened
2018.08.07 18:33:09 3: WEBtablet: port 8085 opened
2018.08.07 18:33:09 1: Including ./log/fhem.save
2018.08.07 18:33:09 0: Featurelevel: 5.8
2018.08.07 18:33:09 0: Server started with 9 defined entities (fhem.pl:17089/2018-08-04 perl:5.024001 os:linux user:fhem pid:5149)
2018.08.07 18:34:39 0: Server shutdown
2018.08.07 18:34:39 1: PERL WARNING: "my" variable $Device masks earlier declaration in same scope at ./FHEM/99_myUtils.pm line 58.
2018.08.07 18:34:39 1: PERL WARNING: "my" variable $Sensor masks earlier declaration in same scope at ./FHEM/99_myUtils.pm line 59.
2018.08.07 18:34:39 1: Including fhem.cfg
2018.08.07 18:34:39 3: telnetPort: port 7072 opened
2018.08.07 18:34:39 3: WEB: port 8083 opened
2018.08.07 18:34:39 3: WEB_ext: port 8086 opened
2018.08.07 18:34:39 3: WEBremote: port 8084 opened
2018.08.07 18:34:39 3: WEBtablet: port 8085 opened
2018.08.07 18:34:39 1: Including ./log/fhem.save
2018.08.07 18:34:39 0: Featurelevel: 5.8
2018.08.07 18:34:39 0: Server started with 9 defined entities (fhem.pl:17089/2018-08-04 perl:5.024001 os:linux user:fhem pid:5168)
2018.08.07 18:36:09 0: Server shutdown
2018.08.07 18:36:10 1: PERL WARNING: "my" variable $Device masks earlier declaration in same scope at ./FHEM/99_myUtils.pm line 58.
2018.08.07 18:36:10 1: PERL WARNING: "my" variable $Sensor masks earlier declaration in same scope at ./FHEM/99_myUtils.pm line 59.
2018.08.07 18:36:10 1: Including fhem.cfg
2018.08.07 18:36:10 3: telnetPort: port 7072 opened
2018.08.07 18:36:10 3: WEB: port 8083 opened
2018.08.07 18:36:10 3: WEB_ext: port 8086 opened
2018.08.07 18:36:10 3: WEBremote: port 8084 opened
2018.08.07 18:36:10 3: WEBtablet: port 8085 opened
2018.08.07 18:36:10 1: Including ./log/fhem.save
2018.08.07 18:36:10 0: Featurelevel: 5.8
2018.08.07 18:36:10 0: Server started with 9 defined entities (fhem.pl:17089/2018-08-04 perl:5.024001 os:linux user:fhem pid:5193)
Der Fehler bleibt. Restart in Endlosschleife
Viele Grüße
Hast mal die myutils leer gemacht?
Gesendet von meinem Doogee S60 mit Tapatalk
Guten Morgen,
nach langem probieren habe ich eine Lösung gefunden.
Alles ausschalten ( inkl. aller Sensor / Aktoren Gateways), Konfig leeren ohne Erfolg.
Was am Ende geholfen hat, fhem.cfg löschen und eine leere anlegen.
Anschließend habe ich ein Backup von vor dem Update genommen, läuft !
Zum Test habe ich die vermeidlich defekte Konfig noch einmal versucht, läuft nicht.
Somit ist die Konfig irgendwie kaputt.
Besten Dank für Eure Hilfe
Viele Grüße
Stefan
Zitat von: Stefan_Ne am 08 August 2018, 09:11:55...Somit ist die Konfig irgendwie kaputt....
Vergleiche doch mal die "kaputte" Config mit der "funktionierenden".
Vielleicht erschließt sich dadurch das Problem und man kann es zukünftig besser eingrenzen bzw. umgehen.
Hallo zusammen,
ich befinde mich gerade im selben Dillema.
Aktuell versuche ich mein fhem vom Raspberry Pi auf einen NUC (Proxmox Container) umzuziehen.
Das Phänomen ist wie bei Stefan, ein Neustart alle ca. 2 Minuten.
Debugging auf global verbose 5 zeigt mit vor dem fhem shutdown immer andere nicht auffällige Einträge.
Ich habe meine Konfiguration schon auf das Minimum zusammengeschrumpft um den Übeltäter zu finden, allerdings ohne Erfolg.
Die ausgelieferter fhem.cfg.demo funktioniert tadellos. Alsbald ich diese durch meine tausche ist es aus.
Hat noch jemand einen Tipp?
2018.12.07 12:10:19 4: Connection accepted from WEB_192.168.XXX.XXX_XXXXX
2018.12.07 12:10:22 5: Starting notify loop for global, 1 event(s), first is SHUTDOWN
2018.12.07 12:10:22 5: createNotifyHash
2018.12.07 12:10:22 4: BlockingCall (HMinfo_archConfigExec): created child (8198), uses telnetPort to connect back
2018.12.07 12:10:22 5: Homemode_MCHome: Events from monitored device global: SHUTDOWN
2018.12.07 12:10:22 5: End notify loop for global
2018.12.07 12:10:22 0: Server shutdown
2018.12.07 12:13:26 4: Connection accepted from WEB_192.168.XXX.XXX_XXXXX
2018.12.07 12:13:28 5: Starting notify loop for global, 1 event(s), first is SHUTDOWN
2018.12.07 12:13:28 5: createNotifyHash
2018.12.07 12:13:28 4: BlockingCall (HMinfo_archConfigExec): created child (8375), uses telnetPort to connect back
2018.12.07 12:13:28 5: Homemode_MCHome: Events from monitored device global: SHUTDOWN
2018.12.07 12:13:28 5: End notify loop for global
2018.12.07 12:13:28 0: Server shutdown
#Homemode entfernt
2018.12.07 12:14:50 5: Notify_SMA_SunnyIsland_Debug: processing time: inverter_processing_time: 0.1027
2018.12.07 12:14:50 5: Notify_SMA_SunnyIsland_Debug: processing time: 0.1027
2018.12.07 12:14:50 5: End notify loop for SMA_SunnyIsland
2018.12.07 12:14:50 4: Connection accepted from WEB_192.168.XXX.XXX_XXXXX: EOF
2018.12.07 12:15:00 5: Starting notify loop for global, 1 event(s), first is SHUTDOWN
2018.12.07 12:15:00 4: BlockingCall (HMinfo_archConfigExec): created child (8466), uses telnetPort to connect back
2018.12.07 12:15:00 5: End notify loop for global
2018.12.07 12:15:00 0: Server shutdown
2018.12.07 12:13:28 5: Homemode_MCHome: Events from monitored device global: SHUTDOWN
Irgendeine User-Regel schaltet Dir Dein FHEM aus ....
Muss nicht unbedingt sein. Der Hinweis kommt aus dem HOMEMODE Modul. Aber das ist nur ein Log aus der NotifyFn vom Modul. Es sagt nur aus das es ein globales Event SHUTDOWN gab. Kann auch ein reguläres systemctl stop fhem gewesen sein.
Hallo Wernieman,
danke für den Hinweis, das war es aber nicht. Ich habe das Device inzwischen auch gelöscht gehabt und es passierte trotzdem noch.
Inzwischen bin ich glaube ich ein Stück weiter und begreifen kann ich es noch nicht.
Ich habe den Tipp von Stefan gerade umgesetzt, meine fhem.cfg auf Textbasis in die Auslieferungs-Config gepackt - was soll ich sagen, noch kein Neustart :-(
Ich teste mal alles durch....
Ich denke das dieses immer wieder starten alle 2 Minuten vom watchdog des systemd kommt. Wieso das so ist kann ich aber nicht genau sagen. Wenn man aber den Parameter Restart in der /etc/systemd/system/fhem.service mal auf no stellt sollte es eigentlich klappen. Ist aber nur zum testen.
Das habe ich gemacht, damit stirbt fhem dann komplett.
Die Indikation ist, dass der shutdown aus fhem kommt.
Abhilfe hat das o.g. kopieren in die existente cfg gebracht. Warum auch immer...
Rechte waren identisch!
Ah okay. Danke für die Info.
Habe das mal getestet. Ich habe lediglich in der fhem.service das
ExecStart=/usr/bin/perl fhem.pl fhem.cfg
nach
ExecStart=/usr/bin/perl fhem.pl fhem.cfg.demo
geändert und dann ein systemctl daemon-reload gemacht.
Und schon startet alle 2 min mein FHEM.
starte ich hingegen ohne den systemd FHEM mittels
/usr/bin/perl fhem.pl fhem.cfg.demo
läuft FHEM durch. Liegt also nicht an der Konfiguration
Ich konnte mein Problem lösen
In der
/etc/systemd/system/multi-user.target.wants/fhem.service
Type=forking
ändern in
Type=simple
Zitat
if the shell script runs an endless loop and does not exit, set Type to simple
Damit läuft es nun wieder
Hi, bei mir war es das gleiche. Ändern zu Type=simple hat die ständigen Neustarts beendet. Danke CoolTux für den Hinweis.
Mfg
Stiv
Bei mir liegt es höchstwahrscheinlich daran das FHEM in einem LXC unter Proxmox läuft. Worauf läuft Dein FHEM?
Desweiteren ist es bei mir so das dies mit der fhem.cfg.demo passiert ist. Mit der fhem.cfg lief es ohne Probleme. Andersrum startet der service erst gar nicht wenn simple gesetzt hat und mit der fhem.cfg starten will. Ist also aktuell keine Lösung des Problems sondern beenden der Auswirkung.
Bei mir läuft es auf einer Zotac Box unter Debian. Alles per configDB am laufen.
Das komische war, bis zum Update lief es ja.
Ich bin nicht so der Linux Profi und google mir das was ich brauche meist zusammen.
Ich habe den Service mit systemd gestartet, und der zeigte bei der Abfrage des status kurz nach dem start schon einen Fehler an und beendete den Dienst um ihn gleich wieder neu zu starten.
Die Frage ist also, warum beendet sich FHEM sofort wieder .....
Hallo zusammen,
das frage ich mich auch. Leider konnte ich bisweilen den Logs (global verbose 5) nichts entnehmen. Hat noch jemand einen Tipp wie man da weiter debuggen kann?
Zitat von: Wernieman am 09 Dezember 2018, 17:03:50
Die Frage ist also, warum beendet sich FHEM sofort wieder .....
Bei mir läuft auch alle, wie bei CoolTux, auf einem NUC im Proxmox Container. Also bin ich nicht verwundert die gleichen Ergebnisse zu sehen. Leider stosse ich auf OS Ebene aber nun völligst an meine viel zu geringen Linux-Kentnisse :-(
Und die Ergebnisse von CoolTux gepaart mit meiner primitiven Umkopieraktion (was seit Freitag problemlos läuft, auch bei restart des Containers / Hosts) stellen mich vor ein Rätsel und halten mich noch vom produktiven Umzug vom RaPi auf den NUC ab.
Danke für jeden Hinweis und viele Grüße,
Marcel
Ich habe aktuell auf meinen zweiten FHEM Schulungssystem die selben Beobachtungen. Kein Container aber eine KVM virtualisierte Maschine. Auch hier die selben Beobachtungen mit fhem.cfg und fhem.cfg.demo
Da ich aktuell eine Schulung vorbereite habe ich leider keine Zeit das intensiv mir an zu schauen.
Nur mal als Schnellschuß ... steht irgendetwas besonderes in der fhem.save auf euren Systemen?
cat /opt/fhem/log/fhem.save
bzw. mal auf shutdown o.ä. gefiltert:
grep -i -e shutdown -e restart -e stop /opt/fhem/log/fhem.save
Hinweis: Hinter dem grep kommt ein kleines I
Ich habe mit der demo cfg gearbeitet und somit auch mit dem demo save und state file.
Grüße
Stimmt ... nur kommt ein fhem-shutdown durch fhem und hat erstmal nichts mit dem System zu tun. Sonst würde im fhe-log doch nichts von shutdown stehen ... oder?
Sorry, mangels Reproduzierbarkeit auf meinen Systemen, bin ich raus ...
Zum reproduzieren.
Aktuelles debian installieren (ich habe ein KVM Host genommen) und sich das aktuelle FHEM mittels apt-get Befehl installieren. Danach die fhem.service anpassen das nicht fhem.cfg sondern fhem.cfg.demo geladen werden soll. Dann systemctl stop fhem und systemctl start fhem machen und schon siehst du das der Befehl nicht abgeschlossen wird. Du kommst also nicht zurück zum promt.
Man kann mit Ctrl + C zurück kommen und FHEM läuft auch, aber wenn Du dann ein systemctl status fhem machst siehst Du nach genau 2 min das die uptime wieder bei 0 an fängt.
Nur habe ich aktuell kein VM-Host zur Verfügung .... und zum umfangreichem testen komme ich erst "im neuen Jahr" .. sorry
Zitat von: Wernieman am 10 Dezember 2018, 16:11:19
Nur habe ich aktuell kein VM-Host zur Verfügung .... und zum umfangreichem testen komme ich erst "im neuen Jahr" .. sorry
Kein Problem. Ganz entspannt.
Grüße
ich hatte das selbe Problem (alle 2 Minuten restart) nach dem Umzug von einem Rpi3 (Jessie) auf Rpi4 (Buster).
Gelöst habe ich es mit dem genannten Fix in der fhem.service
sudo nano /etc/systemd/system/fhem.service
und dort
Type=forking
geändert auf
Type=simple
wie bereits zuvor von CoolTux erwähnt.
Es gibt mittlerweile eine andere Lösung. Kannst Du mir bitte sagen ob Du ein fakelog Device definiert hast und was Du im global Device beim Attribut log zu stehen hast?
Hallo Leon und Prosit 2020
verrätst du mir b bitte welche andere Lösung?
Mein System startet 1-2 mal am Tag unmotiviert neu.........
System auf einem RPi4 mit 4GB und aktuellem Buster
Gruß
Helmut
Zitat von: Helmi55 am 06 Januar 2020, 11:20:35
Hallo Leon und Prosit 2020
verrätst du mir b bitte welche andere Lösung?
Mein System startet 1-2 mal am Tag unmotiviert neu.........
System auf einem RPi4 mit 4GB und aktuellem Buster
Gruß
Helmut
Dein Problem ist definitiv ein anderes. Hier geht es darum das in der Tat alle 2 min (timeout watchdog von systemd) gestartet wurde da der Systemstart von FHEM nicht korrekt abgeschlossen wurde.
ok Danke
Werde noch weiter beobachten und dann evtl. einen neuen thread aufmachen Nice eve
Helmut
Also bei mir kam dieses Verhalten mit dem Setzen des Attributes "nofork=1" im global-Device und ging dann wieder mit dem Löschen des Attributes...
Zitat von: CoolTux am 15 Dezember 2019, 14:11:28
Es gibt mittlerweile eine andere Lösung. Kannst Du mir bitte sagen ob Du ein fakelog Device definiert hast und was Du im global Device beim Attribut log zu stehen hast?
Hallo CoolTux
Nach einem geplanten shutdown habe ich auf einmal das gleiche Problem. Bis heute morgen lief das System noch einwandfrei.
Nun startet es permanent neu. Mit der fhem.cfg.demo läuft es. Auch mit einer älteren fhem.cfg startet es dauernd neu.
Du meintest es gäbe eine andere Lösung ? Das ändern des fhem.service auf "simple" bringt bei mir nichts. Ich habe übrigens
ein fakelog Device definiert und im global Device stehen folgende Attribute:
attr global userattr DbLogExclude DbLogInclude DbLogValueFn:textField-long alexaName alexaRoom cmdIcon devStateIcon devStateIcon:textField-long devStateStyle genericDeviceType:security,ignore,switch,outlet,light,blind,thermometer,thermostat,contact,garage,window,lock,scene homebridgeMapping:textField-long icon sortby webCmd webCmdLabel:textField-long widgetOverride
attr global autoload_undefined_devices 1
attr global logfile ./log/fhem-%Y-%m-%d.log
attr global modpath .
attr global motd SecurityCheck:\
WEBtablet is not password protected\
WEBphone is not password protected\
\
Protect this FHEM installation by configuring the allowed device allowed\
You can disable this message with attr global motd none
attr global statefile ./log/fhem.save
attr global verbose 3
Hier ein paar systemctl status fhem.service Aufrufe:
Jan 11 17:40:46 mymachine systemd[1]: Started FHEM Home Automation.
pi@mymachine:/opt/fhem $ systemctl status fhem.service
● fhem.service - FHEM Home Automation
Loaded: loaded (/etc/systemd/system/fhem.service; enabled; vendor preset: enabled)
Active: deactivating (stop-sigterm) since Sat 2020-01-11 17:40:46 CET; 24s ago
Process: 2978 ExecStart=/usr/bin/perl fhem.pl fhem.cfg (code=exited, status=0/SUCCESS)
Main PID: 2978 (code=exited, status=0/SUCCESS)
Tasks: 3 (limit: 2200)
Memory: 107.3M
CGroup: /system.slice/fhem.service
├─2979 /usr/bin/perl fhem.pl fhem.cfg
├─2991 /usr/bin/perl fhem.pl fhem.cfg
└─2993 /usr/bin/perl fhem.pl fhem.cfg
Jan 11 17:40:46 mymachine systemd[1]: Started FHEM Home Automation.
pi@mymachine:/opt/fhem $ systemctl status fhem.service
● fhem.service - FHEM Home Automation
Loaded: loaded (/etc/systemd/system/fhem.service; enabled; vendor preset: enabled)
Active: deactivating (stop-sigterm) since Sat 2020-01-11 17:41:13 CET; 5s ago
Process: 2998 ExecStart=/usr/bin/perl fhem.pl fhem.cfg (code=exited, status=0/SUCCESS)
Main PID: 2998 (code=exited, status=0/SUCCESS)
Tasks: 1 (limit: 2200)
Memory: 56.7M
CGroup: /system.slice/fhem.service
└─2999 /usr/bin/perl fhem.pl fhem.cfg
Jan 11 17:41:13 mymachine systemd[1]: Started FHEM Home Automation.
pi@mymachine:/opt/fhem $ systemctl status fhem.service
● fhem.service - FHEM Home Automation
Loaded: loaded (/etc/systemd/system/fhem.service; enabled; vendor preset: enabled)
Active: deactivating (stop-sigterm) since Sat 2020-01-11 17:41:40 CET; 7s ago
Process: 3018 ExecStart=/usr/bin/perl fhem.pl fhem.cfg (code=exited, status=0/SUCCESS)
Main PID: 3018 (code=exited, status=0/SUCCESS)
Tasks: 1 (limit: 2200)
Memory: 80.1M
CGroup: /system.slice/fhem.service
└─3019 /usr/bin/perl fhem.pl fhem.cfg
Jan 11 17:41:39 mymachine systemd[1]: Started FHEM Home Automation.
Viele Grüße
Michael
Permanent neu ist aber nicht das selbe wie alle 2 min.
Die Antowrt auf Deine Frage wirst Du im FHEM Log finden /opt/fhem/log/fhem-xxx.log
Zitat von: CoolTux am 11 Januar 2020, 18:07:14
Permanent neu ist aber nicht das selbe wie alle 2 min.
Die Antowrt auf Deine Frage wirst Du im FHEM Log finden /opt/fhem/log/fhem-xxx.log
Leider nicht. Auch dort waren (auch mit Verbose 5) keine Auffälligkeiten zu sehen. Nachdem ich jetzt das global Attribut nofork=1 gesetzt habe,
funktioniert es seltsamerweise wieder. Service läuft seit 30 Minuten.
Seltsam
Zitat von: trabantp60 am 09 Januar 2020, 10:29:02
Also bei mir kam dieses Verhalten mit dem Setzen des Attributes "nofork=1" im global-Device und ging dann wieder mit dem Löschen des Attributes...
Hier ist der Effekt genau entgegengesetzt
Zitat von: CoolTux am 11 Januar 2020, 19:04:23
Seltsam
Hier ist der Effekt genau entgegengesetzt
Finde ich auch seltsam. Ich habe nach einer halben Stunde extra nochmal nofork=0 gesetzt. Sofort fingen wieder
die Neustarts alle 30 Sekunden an. Habe es dann wieder auf nofork=1 gesetzt (man muss schon schnell sein um
das zu ändern bei 30 Sekunden) und seitdem läuft es sofort wieder ohne Neustarts. Ist wirklich seltsam, da bis
heute morgen noch alles ohne Probleme lief , und ich des Pi nur wegen einem Gehäuse Austausch heruntergefahren
habe. Solange es so läuft, ist es mir erstmal egal ;)
Zitat von: CoolTux am 15 Dezember 2019, 14:11:28
Es gibt mittlerweile eine andere Lösung. Kannst Du mir bitte sagen ob Du ein fakelog Device definiert hast und was Du im global Device beim Attribut log zu stehen hast?
Auch wenn ich nicht gefragt war, vielleicht trotzdem von Interesse:
Ich habe ein fakelog-Device definiert und folgendes im global-Device:
attr global logfile ./log/fhem/fhem-%Y-%m.logDas setzen von "Type=simple" in "/etc/systemd/system/multi-user.target.wants/fhem.service" hat bei mir geholfen.
Hallo,
ich hatte das gliche Problem nach dem Umstieg auf einen RPI4. Der RPI ist über LAN mit der FB 7590 verbunden. Fhem startete auch, wenn ich beispielsweise in Update auf die FB aufspielte und diese sich neu startete. Nach langer Suche stellte sich heraus, dass nach dem Deaktivieren des WIFI Moduls die Problebe behoben waren. Ich nutze für das 2,4 und 5 MHz Wlan den gleichen Namen sowie das gleiche Kennwort.
sudo nano /boot/config.txt
# turn wifi off
dtoverlay=disable-wifi
dtoverlay=disable-bt
sudo reboot
Ob dieser Lösungsansatz auch für andere Nutzer sinnvoll ist, kann ich nicht sagen. Bei mir hat es geholfen.
Hallo zusammen,
ich habe seit heute morgen auch das Problem das sich mein FHEM genau alle 30 Sekunden neu startet. Die ganzen Tipps die bisher in diesem Thread genannt wurden funktionieren bei mir leider nicht. Im Log habe ich aber folgendes entdeckt, kann damit aber recht wenig anfangen:
AttributeError: 'bytes' object has no attribute 'register_handler' at line 56
Hi,
da wäre sofort meine Gegenfrage: was war denn vor heute morgen? Update? Konfigänderungen? Platte voll?
df -h
Gruß Otto
Heute morgen war gar nichts ;D. Bin aufgestanden und habe festgestellt das FHEM schwer erreichbar ist bzw. ständig die Verbindung verliert. Die Platte sieht soweit auch ganz gut aus und der Rest auf dem Server scheint auch ohne Probleme zu funktionieren.
Dateisystem GröÃe Benutzt Verf. Verw% Eingehängt auf
/dev/root 30G 12G 17G 41% /
devtmpfs 1,8G 0 1,8G 0% /dev
tmpfs 2,0G 8,0K 2,0G 1% /dev/shm
tmpfs 2,0G 33M 1,9G 2% /run
tmpfs 5,0M 4,0K 5,0M 1% /run/lock
tmpfs 2,0G 0 2,0G 0% /sys/fs/cgroup
/dev/mmcblk0p1 253M 52M 202M 21% /boot
/dev/sda3 850G 28G 779G 4% /srv
tmpfs 391M 0 391M 0% /run/user/1001
üblicherweise passieren solche Fehler nicht von allein sondern nach Eingriff des Admins.
Man kann also drüber nachdenken, welche Änderung wurde gemacht.
Die Datensicherung zurückspielen, die noch gut funktionierte.
Wenn das alles nicht zutrifft, muss man auch von schlimmeren ausgehen: SD Card / HDD kaputt.
Also wenn SD Card dann schnellsten Daten sichern und tauschen!
Also gestern noch alles gut laut Log, dann heute morgen direkt nachdem erkannt wurde das jemand aufgestanden ist der erste Neustart. Wieder taucht dort ein AttributeError auf.
2020.09.27 07:51:40.131 2: RESIDENTS set Bewohner home
2020.09.27 07:51:40.145 1: WakeUp() triggered
2020.09.27 07:51:40.145 1: EcoPower triggered off
AttributeError: 'str' object has no attribute 'decode' at line 54
2020.09.27 07:51:47.547 1: Including fhem.cfg
Das System läuft eigentlich komplett von einer SSD, die SD-Karte wird aktuell nur zum booten benötigt.
Dieser Fehler kommt irgendwie über die Standardausgabe von irgendwas, was von FHEM aufgerufen wird. Ecopower?
Was gibt Dir das zurück?
journalctl -u fhem
Du sagst ja alle 30 sec, was ist wenn Du fhem mal beendest:
sudo systemctl stop fhem
Und dann die fhem demo starten, läuft die durch?
siehe auch https://wiki.fhem.de/wiki/FHEM_startet_nicht_-_Tipps_zur_Fehlersuche
Sep 27 07:51:47 rpi systemd[1]: fhem.service: Main process exited, code=exited, status=255/EXCEPTION
Sep 27 07:51:47 rpi systemd[1]: fhem.service: Failed with result 'exit-code'.
Sep 27 07:51:47 rpi systemd[1]: fhem.service: Service RestartSec=100ms expired, scheduling restart.
Sep 27 07:51:47 rpi systemd[1]: fhem.service: Scheduled restart job, restart counter is at 1.
Sep 27 07:51:47 rpi systemd[1]: Stopped FHEM Home Automation.
Sep 27 07:51:47 rpi systemd[1]: Starting FHEM Home Automation...
Sep 27 07:51:47 rpi systemd[1]: Started FHEM Home Automation.
Sep 27 07:52:16 rpi systemd[1]: fhem.service: Main process exited, code=exited, status=255/EXCEPTION
Sep 27 07:52:16 rpi systemd[1]: fhem.service: Failed with result 'exit-code'.
Sep 27 07:52:16 rpi systemd[1]: fhem.service: Service RestartSec=100ms expired, scheduling restart.
Sep 27 07:52:16 rpi systemd[1]: fhem.service: Scheduled restart job, restart counter is at 2.
Sep 27 07:52:16 rpi systemd[1]: Stopped FHEM Home Automation.
Sep 27 07:52:16 rpi systemd[1]: Starting FHEM Home Automation...
Sep 27 07:52:17 rpi systemd[1]: Started FHEM Home Automation.
BTW, die Demo scheint stabil zu laufen
Sieht so aus, als ob FHEM (ein Modul davon) wirklich crashed. Main process exited, code=exited, status=255/EXCEPTION
Du kannst den Restart rausnehmen (# davor) https://wiki.fhem.de/wiki/Fhem.service_(systemd_unit_file)
Dann wird er wohl nicht neu starten, aber auch nicht am Laufen bleiben :(
Du kannst das Logging hochdrehen (verbose 5)
Du kannst nach EcoPower suchen?
Irgendeine Datenbank voll nicht erreichbar?
Irgendein andere Service nicht erreichbar?
Du kannst Module erstmal deaktivieren. Und dich Stück für Stück vortasten.
z.B. so wie im Wiki beschrieben mit einer leeren Config starten
cd /opt/fhem
sudo -su fhem wget -qO minimal.cfg https://svn.fhem.de/fhem/trunk/fhem/fhem.cfg
sudo perl fhem.pl minimal.cfg
Dann nimmst Du Gerät für Gerät aus Deiner fhem.cfg und aktivierst sie wieder über die Raw Definition. Bis er wieder abstürzt
Update:
Ich habe nun wie unter https://wiki.fhem.de/wiki/FHEM_startet_nicht_-_Tipps_zur_Fehlersuche beschrieben eine Konfiguration vom 25.09. eingespielt die noch stabil laufen zu scheint.
Mal schauen ob ich nun durch den Vergleich der Konfigurationsdateien heraus bekomme was da in der Konfiguration nicht gepasst hat. Scheint aber erst sehr zeitversetzt Auswirkungen gehabt zu haben.
@Otto: Danke für die Unterstützung
Zitat von: acw81 am 27 September 2020, 16:40:17...
Mal schauen ob ich nun durch den Vergleich der Konfigurationsdateien heraus bekomme was da in der Konfiguration nicht gepasst hat. Scheint aber erst sehr zeitversetzt Auswirkungen gehabt zu haben.
...
Ggf auch mal nicht nur die Config auf Unterschiede prüfen lassen, sondern die komplette Installation. Ich hatte auch schon den Fall, dass mir Perl Module zerschossen wurden, die Config aber noch OK war (Stichwort Defekte SD Karte - was bei Deiner SSD aber vermutlich nicht so tragisch ist).