"99_"-module haben doch die eigenschaft automatisch geladen zu werden. aber irgendwas funktioniert bei mir nicht mehr, seit dem letzten fhem update.
der performance monitor meldet nur noch beim start von fhem
2015.08.26 14:34:43 2: Perfmon: ready to watch out for delays greater than one second
danach ist stille. wäre ja eigentlich schön für mein fhem auf fritzbox. :)
es müssten aber regelmässig freeze meldungen kommen. der meldung nach war die datei mindestens einmal "aktiv".
gerade noch mal reboot zum test gemacht. jetzt kam nicht einmal diese meldung, was früher hin und wieder, meine ich, auch schon vorkam. jedenfalls kommen keine freeze meldungen mehr.
# $Id: fhem.pl 9108 2015-08-22 13:18:56Z rudolfkoenig $
# $Id: 00_CUL.pm 9002 2015-07-29 05:46:10Z rudolfkoenig $
# $Id: 10_CUL_HM.pm 9104 2015-08-22 05:38:59Z martinp876 $
# $Id: 14_CUL_TX.pm 6689 2014-10-05 12:27:19Z rudolfkoenig $
# $Id: 14_CUL_WS.pm 8497 2015-04-30 09:23:21Z rudolfkoenig $
# $Id: 98_DOIF.pm 8432 2015-04-13 19:34:11Z damian-s $
# $Id: 01_FHEMWEB.pm 9079 2015-08-16 10:43:51Z rudolfkoenig $
# $Id: 95_FLOORPLAN.pm 8752 2015-06-15 17:10:54Z ulimaass $
# $Id: 92_FileLog.pm 9107 2015-08-22 13:16:05Z rudolfkoenig $
# $Id: 59_HCS.pm 4433 2013-12-21 05:30:49Z tobiasfaust $
# $Id: 00_HMLAN.pm 9103 2015-08-22 05:23:08Z martinp876 $
# $Id: 98_HMinfo.pm 8975 2015-07-26 06:20:41Z martinp876 $
# $Id: 98_HTTPMOD.pm 9005 2015-07-30 18:21:59Z ststrobel $
# $Id: 98_HourCounter.pm 7336 2014-12-27 20:00:00Z john $
# $Id: 98_PID20.pm 7089 2014-11-29 10:58:10Z john99sr $
# $Id: 73_PRESENCE.pm 9111 2015-08-22 16:46:24Z markusbloch $
# $Id: 59_PROPLANTA.pm 8709 2015-06-07 14:32:51Z tpoitzsch $
# $Id: 99_SUNRISE_EL.pm 6765 2014-10-14 18:24:29Z rudolfkoenig $
# $Id: 98_SVG.pm 9114 2015-08-23 09:27:51Z rudolfkoenig $
# $Id: 59_Twilight.pm 8743 2015-06-14 12:14:57Z dietmar63 $
# $Id: 99_Utils.pm 7914 2015-02-08 11:14:10Z rudolfkoenig $
# $Id: 59_Weather.pm 8937 2015-07-11 12:56:21Z borisneubert $
# $Id: 98_WeekdayTimer.pm 8907 2015-07-06 17:41:47Z dietmar63 $
# $Id: 90_at.pm 8326 2015-03-29 13:30:57Z rudolfkoenig $
# $Id: 98_autocreate.pm 9108 2015-08-22 13:18:56Z rudolfkoenig $
# $Id: 98_dewpoint.pm 6757 2014-10-12 18:58:57Z joachim09876 $
# $Id: 98_dummy.pm 8809 2015-06-23 18:02:33Z rudolfkoenig $
# $Id: 91_eventTypes.pm 8725 2015-06-10 09:50:06Z rudolfkoenig $
# $Id: 95_holiday.pm 8723 2015-06-10 09:09:01Z rudolfkoenig $
# $Id: 98_logProxy.pm 8724 2015-06-10 09:17:44Z justme1968 $
# $Id: 32_mailcheck.pm 8869 2015-07-01 20:22:30Z justme1968 $
# $Id: 91_notify.pm 8953 2015-07-13 15:13:06Z rudolfkoenig $
# $Id: 33_readingsGroup.pm 8980 2015-07-26 08:03:43Z justme1968 $
# $Id: 33_readingsHistory.pm 8951 2015-07-12 21:45:34Z justme1968 $
# $Id: 98_statistics.pm 8991 2015-07-27 15:56:28Z tpoitzsch $
# $Id: 98_telnet.pm 8952 2015-07-13 12:30:26Z rudolfkoenig $
# $Id: 91_watchdog.pm 7108 2014-12-01 08:11:34Z rudolfkoenig $
# $Id: 98_weblink.pm 9049 2015-08-09 14:35:41Z rudolfkoenig $
mit mindestens einer weiteren 99'er gibt es auch probleme (separate config datei für homematic schalter mit eigener fw). hier melden auch 2 weitere user seit neuestem probleme, die im zusammenhang mit dieser datei stehen.
kann das jemand bestätigen? oder gibt es eine einstellung, womit man diesen mechanismuss aus "versehen" abschalten" kann?
gruss frank
Zitates müssten aber regelmässig freeze meldungen kommen.
Das ist aber sehr unwissenschaftlich.
99-er Module werden immer geladen (keine Ausnahme). Es sei denn, sie enthalten ein Syntax-Fehler, das sollte aber im Log sichtbar sein. "version 99_" zeigt alle geladenen 99-er Module an, vorausgesetzt, dass $Id: am Anfang richtig gesetzt ist.
ZitatDas ist aber sehr unwissenschaftlich.
aber äusserst empirisch.
da fehlen zwei 99'er. myUtils und performance monitor. das angesprochene problem mit der anderen datei habe ich bereits anders gelösst, dass keine 99'er mehr nötig ist. edit: da ist ja gar kein $ID vorhanden.
# $Id: 99_SUNRISE_EL.pm 6765 2014-10-14 18:24:29Z rudolfkoenig $
# $Id: 99_Utils.pm 7914 2015-02-08 11:14:10Z rudolfkoenig $ fehler oder merkwürdigkeiten, auch mit verbose=3, kann ich bis zur fhem-"start server"-meldung nicht erkennen.
2015.08.27 13:19:25.809 0: Server shutdown
2015.08.27 13:19:32 2: Perfmon: ready to watch out for delays greater than one second
2015.08.27 13:19:33.073 1: Including fhem.cfgich gehe mal davon aus, dass die 99' vor fhem.cfg geladen sein sollten. da taucht die performance monitor meldung ja auch auf. gibt es eine bestimmte reihenfolge des ladens, sodass bei fehlern ein weiteres laden eventuell abgebrochen wird?
komischerweise funktionieren meine funktionen in 99_myutils aber trotzdem. seltsam. da fällt mir gerade auf, dass im performance modul ein internaltimer beim ersten durchlauf gesetzt wird. das selbe vorgehen gab es auch in der nicht funktionierenden config datei für homematic.
edit: mit eingebauter $ID sind jetzt alle 99'er über version anwesend. aber weiterhin keine freezes vom performance monitor.
Zitat von: frank am 27 August 2015, 15:16:16
edit: mit eingebauter $ID sind jetzt alle 99'er über version anwesend. aber weiterhin keine freezes vom performance monitor.
Na sei doch froh ;)
Aber im Ernst: Kannst du alle subs deiner myUtils Dateien aus der Kommandozeile aufrufen und kommen eventuell Fehler, wenn du es versuchst?
Was sagt FHEM, wenn du jeweils ein
reload 99_myUtilsXXXoder
reload 99_perfmonmachst?
da fühlt sich das fritzbox herz wieder wohl. :)
reload 99_perfmon
2015.08.27 15:57:52.241 1: Perfmon: possible freeze starting at 15:57:43, delay is 9.24
mein wissenschaftliches bauchgefühl sagt mir, dass die internaltimer beim automatischen laden der 99er "untergehen". mit einem reload funktionierte auch die 99_hmconfig wieder.
Ich habe den Verdacht, das es mit den Änderungen vom 18. an der fhem.pl mit intAT zu tun hat.
Gesendet von meinem GT-I9295
Edit: Code: [Auswählen]
<br />fhem.pl: next if(!$i || !$intAt{$i}); # deleted in the loop<br />
Diese Zeile habe ich aus fhem.pl (2673) wieder rausgenommen, wurde am 18. eingebaut. Da perfmon bei systemstart mir keine Verzögerungen mehr anzeigte.
ZitatDiese Zeile habe ich aus fhem.pl (2673) wieder rausgenommen, wurde am 18. eingebaut. Da perfmon bei systemstart mir keine Verzögerungen mehr anzeigte.
ohne diese zeile funktioniert es bei mir auch wieder.
Hi,
hab schon mit diesem report gerechnet nachdem ich den homematic und twilight thread gesehen habe.
@Rudi: Zeile fhem.pl (2673) verursacht in mehreren modulen Probleme. Kann das in fhem.pl noch (wieder) anderes behandelt werden oder müssen die module angepasst werden. In der Beschreibung des patches zu #2673 steht "undef Meldungen beseitigen".
vg
joerg
Ich kapiere es noch nicht, wieso eine Pruefung auf einem nicht definierten hash Eintrag ein Problem verursachen kann. Kann mir jemand auf die Spruenge helfen?
konnte es noch nicht untersuchen. sorry.
hier zur ref der twilight thread (gleiche Symptome) http://forum.fhem.de/index.php/topic,40330.msg326522.html#msg326522
vg
joerg
edith: das "warum" ist da auch offen
edith2: ging wohl darum http://forum.fhem.de/index.php/topic,39887.msg323671.html#msg323671 . Ich vermute das läßt sich gefahrlos zurückdrehen (?)
Der allererste InternalTimer wurde seit der Aenderung am 18. nie gestartet.
Habs gefixt und eingecheckt.
danke
meine fritzbox dankt auch mit einem blitzstart. 8)
2015.08.27 22:08:59.220 1: Perfmon: possible freeze starting at 22:08:10, delay is 49.219
die neuerung hat vorhin eine fehlermeldung generiert. aber leider nur mit global verbose=1 und ohne info über den fork anforderer. empirisch gesehen, könnte das presence gewesen sein. aber reine spekulation.
2015.08.28 12:00:30.739 1: Cannot fork: Cannot allocate memory
2015.08.28 12:00:30.743 1: Cannot fork: Cannot allocate memory
2015.08.28 12:00:30.750 1: PERL WARNING: Use of uninitialized value $i in hash element at fhem.pl line 2673.
edit: könnte man nicht stacktrace einen loglevel spendieren. auf dauer verbose=3 erzeugt bei mir einfach zuviel log. generell habe ich immer verbose=1 und hätte dazu gerne ab und zu stacktrace, um weitere hinweise zu erhalten. speziell für fehler, die nur sporadisch auftreten.
Beim gesetzten stacktrace wird bei einem fork-Fehler auf loglevel 3 der Aufruf-Stack protokolliert.
Wenn bei dir bei verbose 3 zuviel log erscheint, dann muss man bei den betroffenen Modul-Maintainer auf die Einhaltung der Log-Level-Regeln pochen.
ZitatWenn bei dir bei verbose 3 zuviel log erscheint, dann muss man bei den betroffenen Modul-Maintainer auf die Einhaltung der Log-Level-Regeln pochen.
ich interpretiere das mal als nein.
hier nun der fehler etwas ausführlicher
2015.08.31 07:00:26.753 1: Cannot fork: Cannot allocate memory
2015.08.31 07:00:26.755 3: stacktrace:
2015.08.31 07:00:26.757 3: main::fhemFork called by FHEM/Blocking.pm (70)
2015.08.31 07:00:26.759 3: main::BlockingCall called by ./FHEM/73_PRESENCE.pm (535)
2015.08.31 07:00:26.760 3: main::PRESENCE_StartLocalScan called by fhem.pl (2681)
2015.08.31 07:00:26.761 3: main::HandleTimeout called by fhem.pl (583)
2015.08.31 07:00:26.763 1: Cannot fork: Cannot allocate memory
2015.08.31 07:00:26.769 1: PERL WARNING: Use of uninitialized value $i in hash element at fhem.pl line 2673.
2015.08.31 07:00:26.776 3: stacktrace:
2015.08.31 07:00:26.778 3: main::__ANON__ called by fhem.pl (2673)
2015.08.31 07:00:26.780 3: main::HandleTimeout called by fhem.pl (583)
edit: eventuell noch interessant, dass ab diesem verhinderten fork presence schon 2 mal warnungen in verbindung mit blocking.pm gemeldet hat. bis hierher seit reboot fast 48 std null warnungen. die situationen sind ähnlich, da zur vollen stunde presence und proplanta (beide nutzen blocking) "kollidieren" können. es wurde aber keine weitere "cannot fork" meldung registriert.
2015.08.31 08:00:07.030 1: PERL WARNING: Use of uninitialized value $temp in scalar chomp at ./FHEM/73_PRESENCE.pm line 617.
2015.08.31 08:00:07.034 3: stacktrace:
2015.08.31 08:00:07.036 3: main::__ANON__ called by ./FHEM/73_PRESENCE.pm (617)
2015.08.31 08:00:07.038 3: main::PRESENCE_DoLocalPingScan called by FHEM/Blocking.pm (88)
2015.08.31 08:00:07.039 3: main::BlockingCall called by ./FHEM/73_PRESENCE.pm (535)
2015.08.31 08:00:07.041 3: main::PRESENCE_StartLocalScan called by fhem.pl (2681)
2015.08.31 08:00:07.043 3: main::HandleTimeout called by fhem.pl (583)
2015.08.31 08:00:07.045 1: PERL WARNING: Use of uninitialized value $temp in string ne at ./FHEM/73_PRESENCE.pm line 618.
2015.08.31 08:00:07.046 3: stacktrace:
2015.08.31 08:00:07.048 3: main::__ANON__ called by ./FHEM/73_PRESENCE.pm (618)
2015.08.31 08:00:07.049 3: main::PRESENCE_DoLocalPingScan called by FHEM/Blocking.pm (88)
2015.08.31 08:00:07.054 3: main::BlockingCall called by ./FHEM/73_PRESENCE.pm (535)
2015.08.31 08:00:07.056 3: main::PRESENCE_StartLocalScan called by fhem.pl (2681)
2015.08.31 08:00:07.057 3: main::HandleTimeout called by fhem.pl (583)
2015.08.31 08:00:07.119 2: PRESENCE (laptop) - error while processing check: Could not execute ping command: "ping -c 4 192.168.1.21"
Wuesste gerne, wer den Eintrag mit uninitialized Index in %intAt reinbaut (Zeile 2673 in fhem.pl), und den Verantwortlichen dann tadeln. Sehe gerade, dass das eigentlich als intern gedachte Variable von viel zu vielen Modulen angefasst wird. Btw. die Meldung sollte mit der aktuellen fhem.pl nicht kommen.
ZitatBtw. die Meldung sollte mit der aktuellen fhem.pl nicht kommen.
"langzeittests" mit fhem sind irgendwie (immer) sinnlos. 8)