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

[Dduieh]

Hallo zusammen,

mein FEHM stürzt regelmäßig in der Nacht ab.

Ich habe mal "attr global verbose 4" eingeschaltet. Der letzte Eintrag ist:

2016.01.15 03:53:55 4: Weather nbg_Wetter_Vorhersage: T: 2  H: 81  W: 13  P: 982
Bizarre copy of ARRAY in scalar assignment at /usr/share/perl/5.14/Carp.pm line 140.

Das ganze ging los, als ich mailcheck integriert habe.
Im RasPi habe ich folgende Befehle dafür ausgeführt:
cpan install Mail::IMAPClient
cpan install IO::Socket::SSL
cpan install IO::Socket::INET
sudo cpan install MIME::Parser

Irgendwie muss das ja damit zusammen hängen. Ich verstehe nur nicht, warum er dann beim Weather-Modul den Geist aufgibt.
Das Wetter wird jede Stunde den ganzen Tag aberufen und es passiert nichts.

Ein FHEM-Update habe ich vor ein paar Tagen gemacht.

Danke für Eure Hilfe

[rudolfkoenig]

Wenn ich die Hinweise im Netz richtig interpretiere, dann ist die Fehlermeldung Folge/Symptom eines Perl Problems (Stack Corrupt). Ich wuerde auf eine neuere Perl Version umsteigen.

[JoWiemann]

Hallo,

könnte es sein, dass MailCheck nicht sauber bei Verlust der Internetverbindung arbeitet?. Jede Nacht deutet auf ein Problem bei Router-Zwangs-Dis- und Reconnect hin. Mach doch mal die Probe und beende die Netzwerkverbindung Deines Fhem-Servers.

Grüße Jörg

[Benni]

könnte es sein, dass MailCheck nicht sauber bei Verlust der Internetverbindung arbeitet?. Jede Nacht deutet auf ein Problem bei Router-Zwangs-Dis- und Reconnect hin

Kann ich teilweise bestätigen.
Mailcheck hat anscheinend ein "Problem" beim Verlust der Internetverbindung.
Auch bei mir wird nächtlich zwangsgetrennt. Das führt dann bei mir im Log zwar zu ein paar Fehlermeldungen mit Bezug auf Mailcheck, allerdings stürzt bei mir das System dadurch nicht ab (bei mir rennt ein Perl 5.14).

Gruß Benni.

Edit: Korrigiere: Kein Problem (!) und keine Fehler- sondern eine Warnmeldung mit korrektem Hinweis auf die fehlende Verbindung

2016.01.14 05:00:37 1: PERL WARNING: Trying command when NOT connected! at /usr/share/perl5/Mail/IMAPClient.pm line 118
   Mail::IMAPClient::LastError('Mail::IMAPClient=HASH(0x8c2a468)', 'NO not connected') called at /usr/share/perl5/Mail/IMAPClient.pm line 1454
   Mail::IMAPClient::_send_line('Mail::IMAPClient=HASH(0x8c2a468)', '1075 SELECT INBOX', 0) called at /usr/share/perl5/Mail/IMAPClient.pm line 1304
   Mail::IMAPClient::_imap_command_do('Mail::IMAPClient=HASH(0x8c2a468)', 'SELECT INBOX') called at /usr/share/perl5/Mail/IMAPClient.pm line 1209
   Mail::IMAPClient::_imap_command('Mail::IMAPClient=HASH(0x8c2a468)', 'SELECT INBOX') called at /usr/share/perl5/Mail/IMAPClient.pm line 832
   Mail::IMAPClient::select('Mail::IMAPClient=HASH(0x8c2a468)', 'INBOX') called at ./FHEM/32_mailcheck.pm line 258
   main::mailcheck_poll(undef) called at fhem.pl line 2816
   main::HandleTimeout() called at fhem.pl line 593

[Dduieh]

Wenn ich die Hinweise im Netz richtig interpretiere, dann ist die Fehlermeldung Folge/Symptom eines Perl Problems (Stack Corrupt). Ich wuerde auf eine neuere Perl Version umsteigen.

Hallo,

wie kann ich denn auf eine neue Perl Version umsteigen?

Danke

[Puschel74]

wie kann ich denn auf eine neue Perl Version umsteigen?

Code Auswählen Erweitern

apt-get install perl
liefert mir z.b. Google.

Aber bitte nicht über die FHEM-Befehlszeile eingeben 

[betateilchen]

@Puschel: das funktioniert nicht...

[Puschel74]

@Puschel: das funktioniert nicht...

Mein RasPi hat das brav geschluckt, ausgeführt und das neue Perl-Paket installiert.
Ich habs vorher selbst ausprobiert.
Neue Version ist v5.14.2

Edith: Ok, root sollte man schon sein 

[betateilchen]

Das install dürfte nur funktionieren, wenn noch kein perl vorhanden ist.
Mit 5.14 bist Du allerdings auch nicht auf dem aktuellen Stand

Code Auswählen Erweitern


root@fhem-dev:/home/udo> apt-get install perl
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
perl ist schon die neueste Version.
perl wurde als manuell installiert festgelegt.
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
root@fhem-dev:/home/udo> perl -v

This is perl 5, version 20, subversion 2 (v5.20.2) built for arm-linux-gnueabihf-thread-multi-64int
(with 42 registered patches, see perl -V for more detail)


[Puschel74]

Das install dürfte nur funktionieren, wenn noch kein perl vorhanden ist.

Ich habs zumindest auf einem RasPi ausgeführt auf dem auch (schon länger) FHEM läuft 
Eigentlich dachte ich das FHEM ein vorhandenes Perl braucht.

[Dduieh]

Zur Info: Es liegt an dem MailCheck Modul. Ich habe es deaktiviert und seit dem gab es keine Abstürze mehr.

[Benni]

Wenn du den Betreff mal noch entsprechend anpasst liest justme1968 als maintainer von mailcheck vielleicht noch hier rein und kann das analysieren.

[justme1968]

das in mailcheck verwende imap modul ist leider nicht wirklich dafür vorgesehen mit einer fremden main loop/select zu laufen und ist bei fehlern etwas anfällig.

wenn du die uhrzeit der zwangstrennung abschätzen kannst am besten das modul mit disabledForIntervalls für diese zeit deaktivieren. wenn die zeiten zu variabel sind mit  presence die Internet verbindung prüfen und mailcheck deaktivieren wenn die verbindung weg ist.

vielleicht hilft es auch statt idle auf pollen umzustellen.

auf die schnelle habe ich leider keine bessere Idee.

eventuell kannst du noch mit einer fhem instanz in der nur mailcheck und sonst nichts läuft noch mal prüfen ob es nur an mailcheck oder am zusammenspiel mit einem anderen modul liegt.

gruss
  andre

[Benni]

Hallo Andre,

Mailcheck kennt leider kein disabledForIntervals.

Gruß Benni.

[justme1968]

du hast recht. ich hatte versucht das einzubauen aber da die imap lib im idle fall selber signalisiert und nicht gepollt wird hat es nicht gepasst. das normale disable mit einem at/WeekdayTimer/DOIF oder was auch immer geht aber.

gruss
  andre

[Benni]

das normale disable mit einem at/WeekdayTimer/DOIF oder was auch immer geht aber.

Das ist dann aber auch jedesmal eine Strukturänderung (Stichwort rotes Fragezeichen).
Aber als Workaround schätzungsweise tolerierbar.

[justme1968]

testet erst mal ob es hilft. dann schauen wir wie wir das fragezeichen nicht beeinflussen.

[Benni]

Ich habe das bei mir gestern Abend mal noch quick'n'dirty mit 2 at eingebaut.
Zwar hatte ich kein Absturzproblem aber damit sind zumindest mal die unschönen Warnmeldungen aus meinem Log verschwunden.

@Dduieh kannst du bitte auch mal noch testen, ob du so deine Absturzproblematik in den Griff bekommst?

[dascrip]

Hallo Zusammen,

ich hänge mich mal dran....

Wie kann ich den mailcheck per AT-Befehl disablen. Einen z.B. bei AT zu schalten kenne ich, aber das mit Mailcheck kriege ich gerade nicht auf die Kette.

BTW: Ich habe das gleiche Problem. Seitdem ich mailcheck einsetze, stürzt mein FHEM unregelmäßig bei der Zwangstrennung ab.

Danke!

Dominik

[Benni]

Na ja, so kompliziert ist es jetzt wirklich nicht:
Über ein at rechtzeitig vor der Zwangstrennung das disable Attribut von mailcheck auf 1 setzen.
Mit einem 2. at das disable Attribut zu einem Zeitpunkt nach der Zwangstrennung wieder löschen.

Der Knackpunkt ist das disable Attribut von mailcheck.
Statt at könnte man bestimmt auch weekdaytimer oder DOIF dazu hernehmen.

[Otto123]

Wer DOIF mag: 

Code Auswählen Erweitern

define di_MailcheckDisable DOIF ([03:00 - 04:30]) (attr mailcheck disable 1) DOELSE (attr mailcheck disable 0)
Bringt allerdings rote Fragezeichen.
So wird es optisch besser:

Code Auswählen Erweitern

define di_MailcheckDisable DOIF ([03:00 - 04:30]) (attr mailcheck disable 1) DOELSE (attr mailcheck disable 0,save)

Gruß Otto

[Benni]

Das Problem mit dem roten Fragezeichen hatte ich weiter oben bereits angesprochen.
Das liegt an der Konfigurationsänderung durch das verändern eines Attributes.

So wird es optisch besser:

Das schon, aber man muss bedenken, dass damit alle bis dahin ungespeicherten Änderungen an der Konfiguration gespeichert werden, das ist u.U. nicht immer gewünscht!

[justme1968]

ich kann gerade nicht selber testen aber versucht mal die angehängte version.

damit gibt es ein set <device> inactive bzw. set <device> active kommando. das triggert das rote Fragezeichen nicht, der inaktive zustand wird aber auch nicht gesichert.

gruss
  andre

[Otto123]

Das schon, aber man muss bedenken, dass damit alle bis dahin ungespeicherten Änderungen an der Konfiguration gespeichert werden, das ist u.U. nicht immer gewünscht!

Deswegen habe ich das ja auch extra vorsichtig erwähnt. Manchmal ist es aber für den "Vergesslichen" auch gar nicht schlecht 

ich wollte ja nur ein ganz konkretes Beispiel liefern.
BTW bei mir schmiert FHEM richtig ab wenn ich das nicht mache!

Bizarre copy of HASH in scalar assignment at /usr/share/perl/5.14/Carp.pm line 140.

Ist der letzte Aufschrei 

[Benni]

ich kann gerade nicht selber testen aber versucht mal die angehängte version.

Ich habe das Modul mal bei mir eingespielt, aber es gibt kein set für das Modul:

No set implemented for ...

[justme1968]

arg... war zwar eingebaut aber nicht aktiviert.

ich habe die version oben aktualisiert.

gruss
  andre

[dascrip]

Hallo Otto,

besten Dank, ich teste mal damit. Da ich alle Änderungen auch immer direkt save, kann ich mit Deiner Version leben.

Danke!

Dominik

[Otto123]

ich habe die version oben aktualisiert.

Hallo Andre,

habe getestet und funktioniert in aller Kürze. Ich werde es mal einen Tag laufen lassen.

Gruß Otto

[Benni]

ich habe die version oben aktualisiert.

Ja, jetzt passt's!

Ich habe es jetzt direkt in meiner Produktivumgebung installiert und meine beiden at entsprechend angepasst.
Schauen wir mal, was bis morgen früh passiert

Gruß Benni.

[Benni]

Hallo Andre,

bei mir hat heute während der Zwangstrennung alles reibungslos funktioniert.
Mailcheck Rechtzeitig vorher auf inactive gesetzt und danach wieder auf active: Keine Fehlermeldungen, kein Absturz und kein rotes Fragezeichen. Mailcheck arbeitet heute morgen ganz normal.

Danke!

Gruß Benni.

[justme1968]

hab es eingecheckt.

gruss
  andre

[rudolfkoenig]

@andre: Vorschlag: disabledForIntervals

[justme1968]

@rudi: das wollte ich eigentlich ursprünglich. das funktioniert aber nicht weil es kein event/callback am anfang und ende der disabled zeit gibt. zumindest nicht ohne selber irgendwelche timer zu implementieren.

so ein event brauche ich aber um das im hintergrund wartende imap idle zu stoppen oder neu zu starten. d.h. das modul rollt nicht sondern wartet passiv im select. das warten muss am anfang des disabled zeitraums aktiv beendet werden. und umgekehrt. lustiger satz

[rudolfkoenig]

Ok, verstanden.

[ulli]

Ich habe seit einigen Tagen das selbe Problem.
Regelmäßig in der Nacht stürzt FHEM ohne Logeintrag außer folgender vollständig ab.

Code Auswählen Erweitern

Bizarre copy of ARRAY in scalar assignment at /usr/share/perl/5.14/Carp.pm line 140.

Ich habe die aktuelle Version von mailcheck vom 15.02.2016.

[justme1968]

hast du mit aktiviertem stacktrace geschaut ob es auch an mailcheck liegt?

wenn ja gibt es bei dir einen zwangstrennung?

wenn ja wie oben beschrieben per at das modul in dieser zeit still legen.

gruss
  andre

[ulli]

Ich habe Stacktrace aktiviert. Es gab aber keine Ausgabe dazu. Es gibt nur diesen einen Eintrag.

[Otto123]

Ulli, geht  mir genau so! 
Während der Zwangstrennung mache ich jetzt Pause für mailcheck. Aber seit zwei Tagen stürzt er einfach so einmal am Tag ab!
Gestern dachte ich hätte das Internet etwas überlastet aber heute war zu der Zeit keiner zu Hause und im Netz nichts los. Ich kann nur am Datum des FHEM log festmachen wann es passiert.

Ist so nicht zu gebrauchen, ich versuche gerade diese System neu zu machen und ne andere Perl Version zu nehmen. Keine Ahnung ob das was bringen wird.

Habe jetzt seit gestern Abend Jessie und damit Perl 5.20 laufen - mal sehen.
Carp.pm damit Version 1.3301 vorher war es 1.20 - Inhalt sieht auf den ersten Blick ganz anders aus.

Gruß Otto

[ulli]

Hi Otto,
ich habe jetzt zwischen 23 und 2 uhr das modul mailcheck deaktiviert...jetzt läuft FHEM durch...danke!

[Ma_Bo]

Hallo, gibt es z.Z. nur die Lösung über das disable oder aktiv/inactive setzen?

Lohnt es sich perl zu aktualisieren oder brauch ich mir die Mühe damit garnicht erst machen?
Bei einer Zwangstrennung kommt es auch bei mir zu einem total Ausfall von fhem, sonst ist es ein super Modul, welches auch ohne Probleme läuft.

Grüße Marcel

[Otto123]

Lohnt es sich perl zu aktualisieren oder brauch ich mir die Mühe damit garnicht erst machen?
Bei einer Zwangstrennung kommt es auch bei mir zu einem total Ausfall von fhem, sonst ist es ein super Modul, welches auch ohne Probleme läuft.

Hallo Marcel,

ich kann das nicht genau sagen, es gibt offenbar zwei Fehlerbilder zumindest hatte ich schon beide:
1. Bei Zwangstrennung (oder Internet Ausfall) wirft ein Perl Modul Fehler ohne Ende und dein Log File ist anschließend quasi Mist.
2. FHEM wird beendet und die letzte Auschrift ist: Bizarre copy of ARRAY in scalar assignment at /usr/share/perl/5.14/Carp.pm

Der 2. Fehler liegt eventuell an der Perl Version, der tritt bei mir jetzt erstmal nicht mehr auf, aber eine Woche ist auch noch zu kurz.
Der 1. Fehler wird auch nicht einfach mit der Perlversion behoben, da ist offenbar noch mehr Arbeit nötig.

Mir ist die Variante mit active/inactive zumindest erstmal hilfreich, nicht schön aber ausreichend.

Gruß Otto

[Ma_Bo]

Hallo Otto,
danke für deine Infos.

Mein mailcheck stell ich ersteinmal ab, da es für mich so nicht funktioniert und meine Anwesenheitskontrolle damit nicht wirklich brauchbar umzusetzen ist.

Ich werde weiterhin mitlesen, evtl. gibt es ja bald eine gute Lösung.

Grüße Marcel

[Benni]

Hallo Andre,

ich muss das Thema leider noch mal hoch holen.

Leider habe ich das Problem, dass meine Internetverbindung hier nicht sehr stabil zu sein scheint (Bin derzeit mobil über einen entsprechenden LTE-Stick online). Die Verbindung bricht also immer mal wieder sporadisch weg (es handelt sich dabei um keine Zwangstrennung!).
Wenn in diesem Zeitraum, aber Mailcheck versucht Daten zu holen, schlägt das fehl und führt dazu, dass FHEM komplett in den Seilen hängt:

Code Auswählen Erweitern


2016.07.11 09:36:58 1: PERL WARNING: Trying command when NOT connected! at /usr/share/perl5/Mail/IMAPClient.pm line 118
Mail::IMAPClient::LastError('Mail::IMAPClient=HASH(0x2635d08)', 'NO not connected') called at /usr/share/perl5/Mail/IMAPClient.pm line 1454
Mail::IMAPClient::_send_line('Mail::IMAPClient=HASH(0x2635d08)', '44 SELECT INBOX', 0) called at /usr/share/perl5/Mail/IMAPClient.pm line 1304
Mail::IMAPClient::_imap_command_do('Mail::IMAPClient=HASH(0x2635d08)', 'SELECT INBOX') called at /usr/share/perl5/Mail/IMAPClient.pm line 1209
Mail::IMAPClient::_imap_command('Mail::IMAPClient=HASH(0x2635d08)', 'SELECT INBOX') called at /usr/share/perl5/Mail/IMAPClient.pm line 832
Mail::IMAPClient::select('Mail::IMAPClient=HASH(0x2635d08)', 'INBOX') called at ./FHEM/32_mailcheck.pm line 274
main::mailcheck_poll(undef) called at fhem.pl line 2781
main::HandleTimeout() called at fhem.pl line 591
2016.07.11 09:36:58 1: PERL WARNING: Trying command when NOT connected! at /usr/share/perl5/Mail/IMAPClient.pm line 118
Mail::IMAPClient::LastError('Mail::IMAPClient=HASH(0x2635d08)', 'NO not connected') called at /usr/share/perl5/Mail/IMAPClient.pm line 1454
Mail::IMAPClient::_send_line('Mail::IMAPClient=HASH(0x2635d08)', '45 IDLE', 0) called at /usr/share/perl5/Mail/IMAPClient.pm line 1304
Mail::IMAPClient::_imap_command_do('Mail::IMAPClient=HASH(0x2635d08)', 'IDLE', '+') called at /usr/share/perl5/Mail/IMAPClient.pm line 1209
Mail::IMAPClient::_imap_command('Mail::IMAPClient=HASH(0x2635d08)', 'IDLE', '+') called at /usr/share/perl5/Mail/IMAPClient.pm line 1104
Mail::IMAPClient::idle('Mail::IMAPClient=HASH(0x2635d08)') 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.11 09:36:58 0: Server shutdown


Folge ist, dass das System (nur FHEM) mehr als 3 Minuten hängt und dann irgendwann mein FHEM-Watchdog zuschlägt:

Code Auswählen Erweitern


2016-07-11_09:27:56 fhem_server V: 7 S: OK!
2016-07-11_09:28:56 fhem_server V: 7 S: OK!
2016-07-11_09:29:56 fhem_server V: 7 S: OK!
2016-07-11_09:30:56 fhem_server V: 7 S: OK!
2016-07-11_09:31:56 fhem_server V: 7 S: OK!
2016-07-11_09:32:57 fhem_server V: 8 S: OK!
2016-07-11_09:33:57 fhem_server V: 8 S: OK!
2016-07-11_09:34:57 fhem_server V: 68 S: OK!
2016-07-11_09:35:57 fhem_server V: 128 S: OK!
2016-07-11_09:36:57 fhem_server V: 188 S: DEAD! 188 seconds
2016-07-11_09:36:57 fhem_server MSG: killing FHEM PID: 19871
2016-07-11_09:40:01 fhem_server V: 50 S: OK!
2016-07-11_09:41:01 fhem_server V: 50 S: OK!


Ich habe mir zwar mal ein PRESENCE-Device eingerichtet das prüft, ob eine Internetverbindung besteht (LAN-Ping auf die google-DNS jede Minute) und falls nicht, das Mailcheck-Device erst mal auf inactive setzt. Allerdings haut das vom Timing her doch zu oft nicht recht hin, so dass Mailcheck schon einen Hänger verursacht, wenn PRESENCE den Verlust des Internets noch gar nicht bemerkt hat.

Lässt sich denn da seitens Mailcheck nichts machen, dass im Fehlerfall nicht gleich das ganze FHEM hängen bleibt?

Gruß Benni.

[justme1968]

wenn dein fhem 'nur' hängen bleibt aber nicht abstürzt:

versuch bitte mal nach zeile 189 zusätzlich ein

Code Auswählen Erweitern

$client->Timeout(10);einzubauen.

gegen das komplett aussteigen versuch ich gerade die abfrage per BlockingCall in einen eigenen prozess zu verlagern. ich weiss aber noch nicht ob das geht.

gruss
  andre

[Benni]

Hallo Andre,

danke für die schnelle Rückmeldung!

Die Code-Zeile habe ich jetzt mal eingefügt.
Ich werde beobachten und berichten.

Bisher ist das System bei mir "nur" hängen geblieben und nicht abgestürzt. Den Neustart hat dann wie schon geschrieben mein Watchdog nach Hängen > 3 Minuten eingeleitet.

[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

[Seli]

Leider muss ich meine Bestätigung wieder zurücknehmen. Obwohl es einmal erfolgreich war (d.h. Internetverbindung war weg, Fehlermeldung mit Stacktrace ohne Hängenbleiben), blieb jetzt das komplette System (nicht nur FHEM) wieder wegen des gleichen Problems hängen. Die Zeile RemoveInternalTimer() war dabei auskommentiert.

Code Auswählen Erweitern

PERL WARNING: Trying command when NOT connected! at /usr/share/perl5/Mail/IMAPClient.pm line 122.
Danach wieder Stacktrace und dann Schluss. 

[conmarti]

Wie definierst du hängenbleiben? Bei mir ist der Prozess fhem.pl abgestürzt und ich mußte ihn neu starten. Wenn du mit Hängenbleiben jedoch meinst, dass das Modul Mailcheck nicht mehr reagiert, dann ist das erstmal normal. Die Lösung dafür habe ich hier https://forum.fhem.de/index.php/topic,14092.msg741545.html#msg741545 beschrieben.

Gruß Conny

[Seli]

Wie ich schrieb blieb wirklich das ganze System hängen. Das bedeutet, dass ich auch nicht mehr über SSH drangekommen bin. Gerade im Moment ist es wieder aufgetreten. Ob es wieder mailcheck war, sehe ich natürlich erst nach dem Reboot.

[Seli]

Da ich den Zustand gerade habe, habe ich nochmal genauer hingeschaut. Ich habe OSMC/Kodi als Basis laufen. Die GUI von Kodi ist noch bedienbar. Somit bleibt doch nicht das ganze System hängen, ich komme nur aus mir unbekannten Gründen nicht mehr per SSH dran. Das habe ich dann falsch interpretiert. Dieses Verhalten ist jedoch jedesmal gleich.

[Seli]

Und wenn man noch genauer hinschaut, merkt man, dass der Raspi ein Netzwerkproblem hat und man dann natürlich auch nicht mehr per SSH drankommt 

Nachdem ich ihn nun per Netzwerkkabel angeschlossen habe sehe ich, dass FHEM munter weiterläuft... Das Auskommentieren der Zeile hat offensichtlich doch geholfen. Entschuldigt bitte die Verwirrung.