Hallo Zusammen,
ich habe hier FHEM schon sehr lange auf einem Raspberry 1 laufen. FHEM wir hier benutzt um 10 Homematic Rollladen zu steuern und um 2 Schalter zu steuern, außerdem habe ich hier noch 4 günstige 433 MHZ Steckdosen mit dem Pilight Modul eingebunden.
Jetzt habe ich das Ganze vor Kurzem auf einen Raspberry 2 umgezogen (komplett, zunächst Image erstellt und dann für den Raspberry 2 auf eine Microsd Karte zurückkopiert).
Hier passiert es nun, das mir der FHEM Server wenigstens einmal am Tag stehenbleibt /abstürzt. Im Fhem Logfile ist nie was zu sehen. Er bleibt quasi einfach stehen. Mit sudo service fhem start kann ich den Server wieder starten.
Das Ganze passiert nur auf dem Raspberry 2. Wenn ich die Ganze Sache wieder auf den Raspberry 1 einspiele, läuft dieser einwandfrei.
Heute hatte ich nun zum 1.mal im Log folgendes:
2015.09.15 06:16:50 3: Nachricht von mytwilight: aktEvent: sr_civil
2015.09.15 06:41:28 4: LICHT_GARTEN(Set): off
2015.09.15 06:41:28 3: CUL_HM set LICHT_TERRASSE_KUECHE off
2015.09.15 06:56:43 3: Nachricht von mytwilight: aktEvent: sr
2015.09.15 06:56:43 3: Nachricht von mytwilight: aktEvent: sr_indoor
2015.09.15 06:56:43 3: Nachricht von mytwilight: aktEvent: sr_weather
2015.09.15 08:23:43 4: HIGHBOARD_LICHT(Set): on
panic: memory wrap at ./FHEM/01_FHEMWEB.pm line 2348.
Ich kann mir keinen Reim drauf machen.
Hat jemand eine Idee, wo ich ansetzen kann?
Achoo falls es hilfreich ist:
perl -v gibt folgendes:
This is perl 5, version 14, subversion 2 (v5.14.2) built for arm-linux-gnueabihf-thread-multi-64int
(with 89 registered patches, see perl -V for more detail)
Gruß
Jens
Was sagen den die Linux-Logfiles?
Unter /var/log zu finden
Wenn FHEM "tot" ist, ist dann der FHEM-Prozess auch "tot"?
ps aux | grep fhem
Der Server an sich hat keine Probleme? Wie sieht dann die uptime aus?
Also fhem Prozess ist dann tot, sprich nicht mehr in der prozessliste.
Mit Service fhem Start läuft das Ganze wieder.
Der Server läuft , es hat kein Reboot oder sowas ähnliches stattgefunden, was ich an der Uptime erkennen kann.
Gesendet von meinem iPhone mit Tapatalk
Mit andren Worten:
FHEM stürzt Dir komplett ab, ohne das Du einen Grund findest?
Das System dagegen läuft sauber durch?
Wobei .. habe erst jetzt gesehen:
panic: memory wrap at ./FHEM/01_FHEMWEB.pm line 2348.
Gibt es zu der Uhrzeit Infos im kern.log? (alternativ syslog, messages o.Ä.)
ZitatMit andren Worten:
FHEM stürzt Dir komplett ab, ohne das Du einen Grund findest?
Das System dagegen läuft sauber durch?
Wobei .. habe erst jetzt gesehen:
Code: [Auswählen]
panic: memory wrap at ./FHEM/01_FHEMWEB.pm line 2348.
Gibt es zu der Uhrzeit Infos im kern.log? (alternativ syslog, messages o.Ä.)
Im kern.log ist der Letzte Eintrag vom 14.09 (Als das System gestartet wurde). Kein Eintrag vom 15.09
Das Message.log zeigt folgendes:
Sep 15 06:25:13 raspi-fhem rsyslogd: [origin software="rsyslogd" swVersion="5.8.11" x-pid="1943" x-info="http://www.rsyslog.com"] rsyslogd was HUPed
Sep 16 06:25:24 raspi-fhem rsyslogd: [origin software="rsyslogd" swVersion="5.8.11" x-pid="1943" x-info="http://www.rsyslog.com"] rsyslogd was HUPedIm Syslog kann ich nur wiederkehrende Einträge sehen, hier läuft anscheinend ein stündlicher cronjob?
Sep 15 07:39:01 raspi-fhem /USR/SBIN/CRON[13360]: (root) CMD ( [ -x /usr/lib/php5/maxlifetime ] && [ -x /usr/lib/php5/sessionclean ] && [ -d /var/lib/php5 ] && /usr/lib/php5/sessionclean /var/lib/php5 $(/usr/lib/php5/maxlifetime))
Sep 15 08:09:01 raspi-fhem /USR/SBIN/CRON[13435]: (root) CMD ( [ -x /usr/lib/php5/maxlifetime ] && [ -x /usr/lib/php5/sessionclean ] && [ -d /var/lib/php5 ] && /usr/lib/php5/sessionclean /var/lib/php5 $(/usr/lib/php5/maxlifetime))
Sep 15 08:17:01 raspi-fhem /USR/SBIN/CRON[13457]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Sep 15 08:39:01 raspi-fhem /USR/SBIN/CRON[13493]: (root) CMD ( [ -x /usr/lib/php5/maxlifetime ] && [ -x /usr/lib/php5/sessionclean ] && [ -d /var/lib/php5 ] && /usr/lib/php5/sessionclean /var/lib/php5 $(/usr/lib/php5/maxlifetime))
Sep 15 09:09:01 raspi-fhem /USR/SBIN/CRON[13544]: (root) CMD ( [ -x /usr/lib/php5/maxlifetime ] && [ -x /usr/lib/php5/sessionclean ] && [ -d /var/lib/php5 ] && /usr/lib/php5/sessionclean /var/lib/php5 $(/usr/lib/php5/maxlifetime))
Sep 15 09:17:01 raspi-fhem /USR/SBIN/CRON[13567]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Sep 15 09:39:01 raspi-fhem /USR/SBIN/CRON[13604]: (root) CMD ( [ -x /usr/lib/php5/maxlifetime ] && [ -x /usr/lib/php5/sessionclean ] && [ -d /var/lib/php5 ] && /usr/lib/php5/sessionclean /var/lib/php5 $(/usr/lib/php5/maxlifetime))
Sep 15 10:09:01 raspi-fhem /USR/SBIN/CRON[13771]: (root) CMD ( [ -x /usr/lib/php5/maxlifetime ] && [ -x /usr/lib/php5/sessionclean ] && [ -d /var/lib/php5 ] && /usr/lib/php5/sessionclean /var/lib/php5 $(/usr/lib/php5/maxlifetime))
Sep 15 10:17:01 raspi-fhem /USR/SBIN/CRON[13789]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)Alle anderen logs zeigen für den Zeitraum nichts.
komisch ....
hast Du genug Speicherplatz? Dann könntest Du mal im FHM ein verbose 5 machen
Zitat von: Wernieman am 17 September 2015, 07:54:15
komisch ....
hast Du genug Speicherplatz? Dann könntest Du mal im FHM ein verbose 5 machen
Jo, genug Platz ist auf der Micro SD Karte noch (ca 25 GB).
Das werde ich mal machen, global auf Verbose 5 setzen.
Allerdings läuft FHEM seit dem ich vorgestern ein Update von CPAN auf die Version 2.1 gemacht habe (vorher war 1.9 irgendwas drauf).
Seitdem ist FHEM noch nicht wieder abgestürzt. Vorher passierte das wirklich wenigstens einmal am Tag zu unterschiedlichen Zeiten.
Ich muß das jetzt mal weiter beobachten.
Gruß
Jens
Hast Du auch alle Perl-Module aktualisiert? Dann könnte es das Verhalten erklären ...
Zitat von: Wernieman am 17 September 2015, 14:06:40
Hast Du auch alle Perl-Module aktualisiert? Dann könnte es das Verhalten erklären ...
Hm, ich meine mit
sudo perl -MCPAN -e shelldann in der CPAN Shell:
install CPANreload cpanmache ich das doch?
Gruß
Jens
Eigentlich aktuallisiert Du damit nur CPAN .. und nicht die Installierten Module (Meines Wissens)
Ja stimmt wohl. Das hAt das Problem auch nicht behoben.
Laut logfole bleibt fhem immer irgendwann stehen nachdem das km200 mithilfe von httputils meine Heizung abfragt. Was ich dabei nicht verstehe, dieselbe konfig läuft / lief einwandfrei auf einem raspi 1.
es ist mir ein Rätsel.
Gesendet von meinem iPhone mit Tapatalk
Ich hànge mich mal mit dran habe das gleiche Problem. Siehe auch den Thread hier:
http://forum.fhem.de/index.php/topic,41443.0.html
Gibt es schon eine Lösungsansatz?
Am besten:
Nicht perl Module mit cpan, sondern mit den Distri Bordmitteln einspielen. Dann wird bei einem Update/Upgrade (solange es funktioniert) keine weiteren fehler produziert.
@danieljo
Funktioniert denn Dein RasPi wieder?
Mein Raspberry Pi2 läuft jetzt auf einer anderen SD-Karte. Das Problem bleibt aber bestehen. Das sich der FHEM Dienst einfach beendet. ÜBer SSH kann ich dann den Deinst wieder starten.
Definitiv nicht in der syslog/kern.log?
Auch nach deaktivieren des Moduls hatte ich weiterhin Fehler auf dem 2er, während die gleiche konfig auf dem alten 1er einwandfrei läuft.
Ich hab jetzt erstmal wieder alles auf den alten 1er am laufen.
Gesendet von meinem iPhone mit Tapatalk
Bei mir steht der übliche Kram in der Sys/kernel log drin. Aber nicht ansatzweise was auf fehler error oder sonst drauf hindeuten läst
Hast Du monit am laufen?
Nein
Wenn nichts in den Logfiles steht, bin ich momentan ratlos. Kannst Du bitte mal die relevanten Parameter (CPU-Auslastung, Speicher u.A.) mitloggen?
Nur mit mehr Daten ist dieses Problem analysierbar ...
Ich werde mal ein paar daten mitloggen. Seit vorgestern abend ist aber kein Absturz mehr zustande gekommen.
Bei unerwarteten Abstürzen könnte die Ausgabe des fhem prozesses auf der Konsole weitere Informationen bieten.
Ich habe bei mir das fhem Startscript etwas erweitert:
perl fhem.pl fhem.cfg > /opt/fhem/log/fhem-console-`date +%Y%m%d%H%M%S`.log 2>&1
Alternativ kannst du auch fhem direkt auf der Konsole starten oder das screen Kommando verwenden.
Gruß,
Gero
Mal ne "dumme" Frage, welche Distri läuft auf dem PI 2 ?
Hatte diese Probleme nämlich mit "Noobs" bin dann zurück auf "Wheezy" und
alles war wieder gut.
Gruß
Jens
Ich werde mal schauen mehr informationen zu erhalten. Aufjedenfall ist FHEM wieder abgeschmiert. Man was nervt das....
Aktuell läuft Whezzy
Zitat von: gero am 30 September 2015, 10:44:53
Bei unerwarteten Abstürzen könnte die Ausgabe des fhem prozesses auf der Konsole weitere Informationen bieten.
Ich habe bei mir das fhem Startscript etwas erweitert:
perl fhem.pl fhem.cfg > /opt/fhem/log/fhem-console-`date +%Y%m%d%H%M%S`.log 2>&1
Alternativ kannst du auch fhem direkt auf der Konsole starten oder das screen Kommando verwenden.
Gruß,
Gero
also ich habe in der Datei ./etc/init.d/fhem deine änderung übernommen. Die neue Log Datei fhem-console wird auch erstellt. Aber bleibt leer.
Eventuell habe ich den Fehler gefunden. Ich habe den RaspberryPi2 gegen eine andere RaspberryPi2 Platine getauscht. Und seit dem scheint es so als würde alles stabil laufen! Läuft allerdings auch erst seit 2 Tagen.
Desweiteren wollte ich die urspürngliche Platine mit einem aktuellen Debian Jessy Image bespielen was auch klappte aber dann bei jedem neustarten sehe ich in der Start Phase "kernel panic" irgendwas mit der secondary cpu .....
vermutlich ist eine der 4 Prozessor Kerne platt.
Ich werde das gleiche Betriebssystem jetzt auf einen älteren Raspberry Pi B+ testen umzu sehen ob es an der Karte am Betriebssystem oder wirklich am RaspberryPi2 lag.
Ich denke ich hab den Fehler nun endgültig gefunden. FHEM ist immer dann abgeschmiert bzw. der komplette Raspberry Pi 2 wenn die CPU Last deutlich hochging. Ich habe dann mal an der Platine am TP1 und TP2 die Spannung kontrolliert und siehe da gerade mal 4,8V was wohl als unterste Grenze gilt. Ich habe mir nun ein kleinen Stepdown Wandler gekauft. Ich habe jetzt ein 12V Netzteil verwendet und der DC-DC Wandler setzt die Spannung jetzt auf 5,1V runter. Der Stepdown Wandler ist jetzt mit ca. 4cm langen 1mm² Kabeln direkt an die Testpunkte verlötet. Ich vermute das entweder der microUSB Stecker vom Netzteil ausgelutscht war und oder die microUSB Buchse des RPi. Dadurch dann hohe Überwangswiderstände/Kontaktprobleme. Das sollte jetzt Geschichte sein. Hinzukommt das die Lastausregelung um einiges deutlich besser geworden ist.
Kannst Du uns verraten, welchen StepDown Regler Du verwendest hast? Wäre sehr optimal ...
Diese hier sind es bei mir geworden.
http://www.ebay.de/itm/1PCS-5A-DC-DC-adjustable-step-down-module-XL4005-XL4005E1-NEW-/191674244805?hash=item2ca0acdec5:g:EzwAAOSwPcVVnNap (http://www.ebay.de/itm/1PCS-5A-DC-DC-adjustable-step-down-module-XL4005-XL4005E1-NEW-/191674244805?hash=item2ca0acdec5:g:EzwAAOSwPcVVnNap)
Aber Achtung bevor man diese Regler an das RaspberryPi anschließt VORHER Die Spannung auf 5V am Poti einstellen und am besten mit einem Tropfen Heißkleber oder ähnlichem gegen verdrehen sichern. Ist die Ausgangspannung einmal auf 5V eingestellt, ist es egal welche Eingangspannung man anlegt es kommen immer 5V raus. (Eingangsspannung muss größer Ausgangsspannung sein). Bis jetzt hatte ich keinen einzigen Absturtz mehr!
Für 5V müsste es eigentlich feste Regler geben ...
Kleiner Hinweis:
Je näher die Eingangsspannung der Ausgangsspannung, so effektiver ist der Regler, braucht aber in der Auslegung mindestens ?1V? mehr ...
?: Kann es nicht genau aus dem Datenblatt entnehmen, deshalb mit "?"
Ja es gibt "feste" Regler sogenannten Linearregler im TO220 Gehäuse 7805 ist zum Bsp. so einer. Aber jenach abnahme Leistung müssen diese zusätzlich gekühlt werden umso höher die Eingangsspannung ist. Der Wirkungsgrad bei den Step-Down Wandler liegt bei etwa 87% und werden nichtmal Handwarm. Abgabe Leistung liegt bei 2-3A also ausreichend.
Aktueller Stand -> Seit dem Umbau der Stromversorgung KEIN aussetzer mehr!
Du hast mich falsch verstanden, es gibt auch StepDown-Regler, welche fest eingestellt sind. Genau so wie es auch Linear-Regler gib, welche Stufenlos einstellbar sind.
Zitat von: Wernieman am 25 Oktober 2015, 19:51:42
Du hast mich falsch verstanden, es gibt auch StepDown-Regler, welche fest eingestellt sind. Genau so wie es auch Linear-Regler gib, welche Stufenlos einstellbar sind.
Achso meinst du das ja die gibt es auch :) Habe mich aber für die einstellbaren entschieden. So kann ich die Spannung innerhalb der Toleranzen etwas anheben um Verluste in der Leitung zu umgehen. Ich habe ihn auf 5,1V eingestellt. Am RPi selber habe ich am GPIO Port 5,03V gemessen. Jedenfalls läuft das ganze äußerst stabil. Un da hängen jetzt einige Sensoren dran nen WLAN Stick der selbst schon etwas Leistung verheizt usw. Wie gesagt läuft schön stabil jetzt wie es soll.
Habe heute noch den Low-Pass (Bandpassfilter) für den 433Mhz Empfänger angeschlossen. Jetzt ist die CPU Last auch etwas geringer. Aber das ist eher was für die pilight mit Benutzer unter uns :-X
Hallo zusammen,
ich haeng mich mal mit ran...
Ich hab seit 3 Tagen unvermittelte Abstuerze. FHEM bleibt einfach stehen. Der Prozess ist zwar noch da, aber es tut sich nichts mehr. Telnet kann ich noch oeffnen, aber auch da, keine Reation.
Jetzt hab ich schon einene komplett neuen RasPi2 aufgesetzt, mit neuer SD und FHEM neu installiert. Alles ohne Erfolg...
Ich habe jedoch einen Verdacht:
Ich generiere via ImageMagic SVGs zu PNGs die ich dann auf Kindles als Screensaver ansehe. Jetzt ist es mir schon manchmal passiert, dass ich bei manuellen Aufruf des SVGs http://meinfhemserver:8083/fhem/www/images/bla.png keine Antwort bekomme und FHEM im gleichen Augenblick die Segel streicht. Ohne Fehlermeldung im fhem-log, einfach so.
Ich bin langsam echt am verzweifeln ;-(
Gruß
Markus