Jede Nacht stürzt das System ab (wegen mailcheck - Modul)

[Benni]

Hallo Andre,

also ... die Hänger bleiben mit dem kurzen Timeout jetzt auf jeden Fall schon mal aus

Allerdings hatte ich es jetzt schon 2 mal, dass ich bei Ausfall noch zusätzlich eine Fehlermeldung von wegen "found and deleted bad fleno for <MailCheck-Device>" bekommen habe:

Code Auswählen Erweitern


2016.07.13 13:17:22 1: PERL WARNING: Trying command when NOT connected! at /usr/share/perl5/Mail/IMAPClient.pm line 118
Mail::IMAPClient::LastError('Mail::IMAPClient=HASH(0x2ae4438)', 'NO not connected') called at /usr/share/perl5/Mail/IMAPClient.pm line 1454
Mail::IMAPClient::_send_line('Mail::IMAPClient=HASH(0x2ae4438)', '21 SELECT INBOX', 0) called at /usr/share/perl5/Mail/IMAPClient.pm line 1304
Mail::IMAPClient::_imap_command_do('Mail::IMAPClient=HASH(0x2ae4438)', 'SELECT INBOX') called at /usr/share/perl5/Mail/IMAPClient.pm line 1209
Mail::IMAPClient::_imap_command('Mail::IMAPClient=HASH(0x2ae4438)', 'SELECT INBOX') called at /usr/share/perl5/Mail/IMAPClient.pm line 832
Mail::IMAPClient::select('Mail::IMAPClient=HASH(0x2ae4438)', 'INBOX') called at ./FHEM/32_mailcheck.pm line 275
main::mailcheck_poll(undef) called at fhem.pl line 2781
main::HandleTimeout() called at fhem.pl line 591
2016.07.13 13:17:22 1: PERL WARNING: Trying command when NOT connected! at /usr/share/perl5/Mail/IMAPClient.pm line 118
Mail::IMAPClient::LastError('Mail::IMAPClient=HASH(0x2ae4438)', 'NO not connected') called at /usr/share/perl5/Mail/IMAPClient.pm line 1454
Mail::IMAPClient::_send_line('Mail::IMAPClient=HASH(0x2ae4438)', '22 IDLE', 0) called at /usr/share/perl5/Mail/IMAPClient.pm line 1304
Mail::IMAPClient::_imap_command_do('Mail::IMAPClient=HASH(0x2ae4438)', 'IDLE', '+') called at /usr/share/perl5/Mail/IMAPClient.pm line 1209
Mail::IMAPClient::_imap_command('Mail::IMAPClient=HASH(0x2ae4438)', 'IDLE', '+') called at /usr/share/perl5/Mail/IMAPClient.pm line 1104
Mail::IMAPClient::idle('Mail::IMAPClient=HASH(0x2ae4438)') called at ./FHEM/32_mailcheck.pm line 276
main::mailcheck_poll(undef) called at fhem.pl line 2781
main::HandleTimeout() called at fhem.pl line 591
2016.07.13 13:17:22 1: ERROR: Select error -1 (9), error count= 0
2016.07.13 13:17:22 1: Found and deleted bad fileno for mcPresence

(mcPresence ist mein MailCheck-Device)

Anschließend hat MailCheck nicht mehr gecheckt. Erst nachdem ich ein set active gemacht habe, hat es wieder funktioniert. Der Status war aber davor auch schon auf "logged in"

[Lichti]

Hallo,

habe auch das Problem und eine Frage:

wenn ich
define MailcheckDisable DOIF ([03:00 - 04:30]) (attr mailcheck disable 1) DOELSE (attr mailcheck disable 0)
einbaue, brauche ich dann einen 2. define um Mailcheck wieder zu aktivieren oder wird das alles im ersten erledigt ?

Danke und Gruß

[Otto123]

Hi,

das funktioniert so, bringt allerdings ein rotes Fragezeichen 

Du kannst aber auch

Code Auswählen Erweitern

define MailcheckDisable DOIF ([03:00 - 04:30]) (set mailcheck inactive) DOELSE (set mailcheck active) Ohne rotes Fragezeichen machen --> http://fhem.de/commandref.html#mailcheck

Gruß Otto

[Lichti]

Danke.
Werde es mal so probieren.
Und hoffe, es hilft ...

[hartenthaler]

Ich hatte heute einen fhem-Absturz mit ungeklärter Ursache. Die letzten Log-File-Meldungen waren

Code Auswählen Erweitern


2017.02.05 11:36:32 2: huebridge1: http request failed: connect to http://192.168.2.80:80 timed out
2017.02.05 11:36:33 2: huebridge1: http request failed: 192.168.2.80: Keine Route zum Zielrechner
Can't call method "isa" on an undefined value at /usr/local/share/perl/5.20.2/Mail/IMAPClient.pm line 1857.
2017.02.05 11:36:47 3: FRITZBOX Fritzbox: Web_Query.4586 Error: 500 Can't connect to fritz.box:80


Es scheint aber vielleicht eine andere Ursache als IMAPClient.pm gehabt zu haben , da es davor etliche Meldungen wg. nicht vorhandener Netzverbindungen gab.

[Benni]

Code Auswählen Erweitern


Can't connect to fritz.box:80


Du hattest wohl ganz allgemein Verbindungsprobleme  bei dir im LAN, es hat anscheinend schon netzintern nicht funktioniert, dann kann auch kein Internet da sein (Fritz!Box dürfte schätzungsweise das Gateway ins WAN sein)

Dass mailcheck u.U. für Abstürze sorgt, wenn kein Internet da ist ist nicht neu, aber die Ursache für dein Problem ist die nicht funktionierende Netzwerk-Konnektivität.

Musst mal schauen, was da bei dir los ist/war.

[Lichti]

Habe jetzt zusätzlich zum MailcheckDisable von 03:00 bis 04:00 noch einen Job eingebaut, welcher zu jeder vollen Stunde überprüft ob FHEM läuft.
Wenn nicht, wird neu gestartet.

Kam zwar selten vor, aber wenn tagsüber mal das Internet ausfällt hat sich FHEM auch verabschiedet.
Jetzt läuft es dann spätestens nach 1 Stunde wieder.

Schön wäre natürlich, wenn sich das Problem selbst irgendwie beseitigen liese.

[Bison]

Hallo Lichti,

kannst du kurz die Routine zum überprüfen und durchstarten von FHEM posten. Habe seit 4 Wochen das Problem des abstürzenden FHEM Servers

Danke

[Lichti]

Hm, muss ich mal sehen ob ich das noch zusammemkriege, wie ich das damals gemacht habe.

Es wird jedenfalls jede Stunde geprüft, ob FHEM läuft.
Ich habe ein fish-dish Board im Raspi, wo ich mit den LEDs verschiedene Status-Zustände anzeige.
Die gelbe LED wird von FHEM zu jeder Stunde eingeschaltet. Und 1 Minute später wird vom Sytem überprüft, ob sie an ist.
Wenn an: LED ausschalten
Sonst: FHEM steht, REBOOT

Geht sicher auch einfacher, aber so habe ich keine Probleme mehr mit dem mailcheck gehabt.

Weiteres in der angehängten Textdatei

[conmarti]

Hallo zusammen,

nachdem mich das Problem mit den Abstürzen von FHEM auch seit der Nutzung des Moduls Mailcheck plagt, bin ich mal auf die Suche gegangen, was dafür die Ursache sein könnte. Nachdem ich hier und da ein paar Debug-Ausgaben eingebaut habe, hat sich herauskristallisiert, dass die Codezeile RemoveInternalTimer($hash) in der Funktion mailcheck_poll höchstwahrscheinlich die Ursache dafür ist. Denn durch das entfernen der Referenz auf die Timerfunktion, die gerade ausgeführt wird, kommt es zu einer Stack-korruption. Die macht jedoch nur dann Probleme, wenn der Stack ausgegeben werden soll. Das ist immer dann der Fall, wenn Mail::IMAPClient, aus welchem Grund auch immer, auf einen Fehler läuft. Vermehrt traten die Abstürze Nachts während der "Zwangstrennung" der Internetverbindung auf.

Lange Rede kurzer Sinn: Wer auch das Problem hat, sollte die Zeile 269 (RemoveInternalTimer($hash) in der Datei <fhem_home/FHEM/32_mailcheck.pm mal auskommentieren. Bei mir hat es jedenfalls geholfen.

Gruß Conny

[Seli]

@conmarti: Vielen Dank, das werde ich mal testen. Diesen Monat ist mir FHEM bereits zum zweiten Mal wegen diesem Problem abgestürzt.
Ich habe mal versucht herauszufinden, ob RemoveInternalTimer bei Abarbeitung der Timerfunktion aufzurufen ist. Die DevelopmentModuleAPI würde ich so interpretieren, dass RemoveInternalTimer anstehende Timer löscht. Ein Timer, welcher bereits zugeschlagen hat, muss daher nicht gelöscht werden. Auf der anderen Seite habe ich auf Anhieb einige Module gefunden, bei denen der Timer ebenfalls innerhalb der Timer-Routine gelöscht wird. Manchmal wird

Code Auswählen Erweitern

if(!$hash->{LOCAL}) { RemoveInternalTimer ($hash) }
aufgerufen. Was ist denn nun richtig?? Leider habe ich von der FHEM-Modul-Programmierung keine Ahnung.

Grüße,
Seli

[conmarti]

ich habe mir den Perlcode zum Timer angeschaut. Nach Ausführung des Timers wird der gelöscht. Es ist also nicht nötig den "eigenen" Timer zu löschen. In der Regel macht das aber auch kein Problem den Timer trotzdem zu löschen. Erst wenn irgendeine Programmlogik nach dem Löschen ausgeführt wird, welcheauf den Call-Stack zugreifen möchte, kommt es zu diesem Problem. Bei Mailcheck ist das immer dann der Fall, wenn bei der Kommunikation mit dem Mailserver irgendwas schiefgeht. Damit man in einem solchen Fall möglichst viele Informationen zum eingrenzen des Fehlers zur Verfügung hat, wird versucht den Call-Stack ins Log auszugeben. Durch das Löschen des Timers ist dieser aber "Korrupt". In anderen Modulen erfolgen vermutlich keine Zugriffe auf den Call-Stack nach dem Löschen des Timers.

Gruß Conny

[rudolfkoenig]

@conmarti: du suggerierst, dass ein stacktrace() Aufruf die Ursache des Absturzes ist.
Wenn diese Hypothese stimmt, dann wuerde es reichen, stacktrace auszukommentieren.
Kannst du einen einfach zu reproduzierenden Fall bauen?

[Seli]

Ich kann bestätigen, dass das Auskommentieren der Zeile hilft. Mailcheck hatte mal wieder ein Problem mit der Internetverbindung (Ursache nicht bekannt), Stacktrace im Log, und fhem lief diesmal weiter. Vielen Dank an @conmarti für die Lösung dieses Problems!!

[conmarti]

@conmarti: du suggerierst, dass ein stacktrace() Aufruf die Ursache des Absturzes ist.
Wenn diese Hypothese stimmt, dann wuerde es reichen, stacktrace auszukommentieren.
Kannst du einen einfach zu reproduzierenden Fall bauen?

Habe ich schon gemacht. Siehe zweiter Teil meines Posts https://forum.fhem.de/index.php/topic,14092.msg741545.html#msg741545 und dessen Anhang.
stacktrace() ist jedoch nicht die Ursache des Absturz. Hier ist es der Zugriff auf den Stack mittels der Methoden aus dem Modul Carp, welches in Mail::IMAPClient verwendet wird. Der Unterschied zu stacktrace() besteht darin, dass mittels Carp auch die Argumente des Funktionsaufrufes ausgegeben werden, welche nach RemoveInternalTimer nicht mehr "gültig" sind.

Gruß Conny