Hallo Zusammen,
kann es sein, dass Mailcheck mein FHEM abschießt?
2020.10.06 07:42:38 1: PERL WARNING: Use of uninitialized value $from in concatenation (.) or string at ./FHEM/32_mailcheck.pm line 395.
2020.10.06 07:42:38 1: PERL WARNING: Use of uninitialized value $from in pattern match (m//) at ./FHEM/32_mailcheck.pm line 396.
2020.10.06 07:42:38 1: PERL WARNING: Use of uninitialized value $subject in concatenation (.) or string at ./FHEM/32_mailcheck.pm line 401.
2020.10.06 07:42:38 1: PERL WARNING: Use of uninitialized value $message in concatenation (.) or string at ./FHEM/32_mailcheck.pm line 406.
parse_data: No data passed at ./FHEM/32_mailcheck.pm line 410.
2020.10.06 07:42:39 1: PERL WARNING: "my" variable $Stadtteil masks earlier declaration in same scope at ./FHEM/99_myUtils.pm line 194.
2020.10.06 07:42:39 1: PERL WARNING: "my" variable $Stadt masks earlier declaration in same scope at ./FHEM/99_myUtils.pm line 207.
2020.10.06 07:42:39 2: Perfmon: ready to watch out for delays greater than one second
2020.10.06 07:42:39 1: Including fhem.cfg
2020.10.06 07:42:39 3: telnetPort: port 7072 opened
2020.10.06 07:42:39 3: WEB: port 8083 opened
2020.10.06 07:42:39 3: WEBphone: port 8084 opened
Wenn dem so ist, was kann ich dagegen tun. Mein Fhem lief die letzten Monate ultrastabil, Mailcheck macht mir da Sorgen.
Gruß Günter
Wieso soll fhem abgeschossen sein!?
Im Log ist außer WARNINGS!! nichts zu sehen außer einem "normalen Start": Ports offen...
Das hier ist auf jeden Fall wohl "bei dir" nicht ganz stimmig ;) :
Zitat
2020.10.06 07:42:39 1: PERL WARNING: "my" variable $Stadtteil masks earlier declaration in same scope at ./FHEM/99_myUtils.pm line 194.
2020.10.06 07:42:39 1: PERL WARNING: "my" variable $Stadt masks earlier declaration in same scope at ./FHEM/99_myUtils.pm line 207.
Gruß, Joachim
Hallo Joachim,
das ist ja der Punkt. ICH hatte Fhem nicht neu gestartet und frage mich nach dem "Warum ist Fhem mal einfach so neu gestartet?
Das waren halt die letzten Einträge im Log.
Ich kann mich daran erinnern, dass wenn die Zwangstrennung kommt, es bei dem Modul schon mal zum Abschuss von Fhem gekommen ist.
Gruß Günter
Dann fehlt aber halt der "Absturz"...
...also im Log kann ich nichts sehen.
Nur den (halben) Start...
Ansonsten gibt es ja im Wiki noch Möglichkeiten, u.a. debugging, also evtl. mal im Debugger starten: https://wiki.fhem.de/wiki/FHEM_startet_nicht_-_Tipps_zur_Fehlersuche#Neue_M.C3.B6glichkeit_des_Debuggen
Gruß, Joachim
Hi,
das mit mailcheck, war gefühlt "schon immer" so. Internet weg war der Tod für mailcheck mit Folgeerscheinung. Ich habe das dann bei mir ausgesondert. Ich glaube später wurde da mal dran gearbeitet.
Ich lese bei Dir FHEM 5.9 also je nach dem ob Du eine alte oder die aktuelle Version hast, könnte das auch entscheidend sein.
Gruß Otto
Zitat von: MadMax-FHEM am 06 Oktober 2020, 09:09:21
Dann fehlt aber halt der "Absturz"...
...also im Log kann ich nichts sehen.
Der Absturz ist eindeutig zu sehen. Er passiert exakt in dem Moment, wenn die Methode parse_data() aufgerufen wird, um eine (nicht vorhandene) email zu verarbeiten.
parse_data: No data passed at ./FHEM/32_mailcheck.pm line 410.Am fehlenden timestamp bei dieser Meldung erkennt man, dass die nicht aus FHEM kommt, sondern von der Betriebssystemebene.
Danach startet FHEM neu.
Zitat von: MadMax-FHEM am 06 Oktober 2020, 08:44:39
Das hier ist auf jeden Fall wohl "bei dir" nicht ganz stimmig
Stimmt, das hat aber mit dem mailcheck Problem nichts zu tun.
Die Meldung stammt bereits aus dem FHEM Neustart und tritt beim Laden der Datei 99_myUtils.pm auf.
Unsaubere Programmierung in der vom Benutzer erstellten Datei, die man beheben sollte.
Zitat von: Otto123 am 06 Oktober 2020, 12:55:05
das mit mailcheck, war gefühlt "schon immer" so. Internet weg war der Tod für mailcheck mit Folgeerscheinung.
Ist leider so. Hab es über einen kleine "workaround" über ein DOIF gelöst. Nicht schön, aber dadurch läuft es einigermaßen zuverlässig. ;-)
([01:00-23:00,+00:30] and [mailcheck:STATE] eq "Logged in")
(set mailcheck inactive,set mailcheck active)