Endlosschleife in Astro bei NewDay-Trigger & Zeitumstellung

[Beta-User]

Kannst du mal in deinem Testsystem die Zeilen am #2518 versuchsweise tauschen:

Code Auswählen Erweitern

    if ( $comp eq 'NewDay' ) {
        my $dch = localtime($now + 86400 + 3600*((localtime($now))[8] - (localtime($now + 86400.))[8]));
        push @next,
          _timelocal_modern( 0, 0, 0, ($dch)[3,4], ($dch)[5]+1900. );
        next;
    }


Ergänzend sollt man z.B. in #776 noch Folgendes einfügen:

Code Auswählen Erweitern

return 'Astro may not be run on Windows systems' if $^O eq 'MSWin32';

[rob]

Hallo Beta-User.

Habe die Änderungen hoffentlich richtig eingesetzt. Die Ergänzung #776 ist auch mit drin. Reload ausgeführt. Zeit zurückgedreht auf 23:59 und wieder abgewartet.

Beobachtung:
Mit Umschaltung 00:00 WebIF weiter verfügbar + reagiert, CPU schaut normal aus (cpan-outdated springt als einziges ab und zu auf 100%)

Habe allerdings dauernd reconnects zum WebIF. Nach Connection lost kommt dann mit F5 ein "Fehler: Verbindung fehlgeschlagen". Nach ein paar Sekunden wieder alles OK. Dann von vorne. Vielleicht habe ich die Editierung noch einen Fehler reingepastet?
Zumindest besteht bereits der Unterschied, dass es erreichbar bleibt.

VG
rob

Edit: die Reconnect liegen daran, dass Fhem dauernd neu startet. Ich fang nochmal frisch an, damit das vergleichbar bleibt.

[Beta-User]

Habe allerdings dauernd reconnects zum WebIF. Nach Connection lost kommt dann mit F5 ein "Fehler: Verbindung fehlgeschlagen". Nach ein paar Sekunden wieder alles OK. Dann von vorne. Vielleicht habe ich die Editierung noch einen Fehler reingepastet?

Glaube ich nicht; vermutlich ist FHEM einfach bei so einem Monatswechsel etwas beschäftigt, so dass longpoll nicht hinreichend schnell bedient wird.

Danke für den Test

@pah: anbei die komplette Datei. Soweit ich das im Kopf habe bevorzugst du diese Variante gg. einem patch.

[rob]

Die Testumgebung lief ja noch. Wollte ausschließen, dass irgendwas im System sich daran stört, wenn ich ich Zeit einfach zurückdrehe 
Also neu begonnen.

- Container resettet
- Zeit auf 23:50Uhr
- Container gestartet
- Devices etc. eingerichtet[/li][/list]
→ Alles OK

Astro.pm geändert + reload
→ Alles OK

Mit Umschaltung auf 00:00 → reconnects/ restarts
Zeit vorgestellt auf 00:59 und abgewartet bis 01:00Uhr → reconnect/restarts bleiben

Astro wieder zurückgepatched + reload (bzw. wg. deuerndem restart zieht es eh von allein) → alles stabil

Irgendwas will da noch nicht so ganz. Habe ich etwas übersehen?

[Beta-User]

Ups, nicht gut... Wenn es einen Neustart gibt, sollte eigentlich was dazu im Log stehen?

[rob]

Schaut so aus:

Code Auswählen Erweitern


2021.10.31 00:00:00.009 1: PERL WARNING: Use of uninitialized value in addition (+) at ./FHEM/95_Astro.pm line 2522.
Day '' out of range 1..31 at ./FHEM/95_Astro.pm line 1293.
2021.10.31 00:00:10.671 3: From the FHEM_GLOBALATTR environment: attr global updateInBackground 1
2021.10.31 00:00:10.671 3: From the FHEM_GLOBALATTR environment: attr global nofork 0
2021.10.31 00:00:10.671 3: From the FHEM_GLOBALATTR environment: attr global logfile ./log/fhem-%Y-%m-%d.log
2021.10.31 00:00:10.671 3: From the FHEM_GLOBALATTR environment: attr global pidfilename ./log/fhem.pid
2021.10.31 00:00:10.673 1: Including fhem.cfg
2021.10.31 00:00:10.755 3: WEB: port 8083 opened
2021.10.31 00:00:10.772 2: eventTypes: loaded 0 events from ./log/eventTypes.txt
2021.10.31 00:00:10.891 3: AptToDate (fhemServerApt) - defined
2021.10.31 00:00:11.137 3: telnetPort: port 7072 opened
2021.10.31 00:00:11.226 1: Including ./log/fhem.save
2021.10.31 00:00:11.234 3: From the FHEM_GLOBALATTR environment: attr global updateInBackground 1
2021.10.31 00:00:11.234 3: From the FHEM_GLOBALATTR environment: attr global nofork 0
2021.10.31 00:00:11.234 3: From the FHEM_GLOBALATTR environment: attr global logfile ./log/fhem-%Y-%m-%d.log
2021.10.31 00:00:11.234 3: From the FHEM_GLOBALATTR environment: attr global pidfilename ./log/fhem.pid
2021.10.31 00:00:11.234 1: Messages collected while initializing FHEM:SecurityCheck:
  telnetPort is not password protected
  WEB is not password protected

Protect this FHEM installation by defining an allowed device with define allowed allowed
You can disable this message with attr global motd none

2021.10.31 00:00:11.933 1: usb create starting
2021.10.31 00:00:11.948 1: usb create end
2021.10.31 00:00:11.948 0: Featurelevel: 6
2021.10.31 00:00:11.948 0: Server started with 16 defined entities (fhem.pl:22522/2020-08-02 perl:5.028001 os:linux user:fhem pid:13474)
2021.10.31 00:00:16.237 1: PERL WARNING: Use of uninitialized value in addition (+) at ./FHEM/95_Astro.pm line 2522.
Day '' out of range 1..31 at ./FHEM/95_Astro.pm line 1293.
2021.10.31 00:00:26.675 3: From the FHEM_GLOBALATTR environment: attr global logfile ./log/fhem-%Y-%m-%d.log
2021.10.31 00:00:26.675 3: From the FHEM_GLOBALATTR environment: attr global pidfilename ./log/fhem.pid
2021.10.31 00:00:26.675 3: From the FHEM_GLOBALATTR environment: attr global updateInBackground 1
2021.10.31 00:00:26.675 3: From the FHEM_GLOBALATTR environment: attr global nofork 0
2021.10.31 00:00:26.677 1: Including fhem.cfg
2021.10.31 00:00:26.760 3: WEB: port 8083 opened
2021.10.31 00:00:26.777 2: eventTypes: loaded 0 events from ./log/eventTypes.txt
2021.10.31 00:00:26.896 3: AptToDate (fhemServerApt) - defined
2021.10.31 00:00:27.139 3: telnetPort: port 7072 opened
2021.10.31 00:00:27.204 1: Including ./log/fhem.save
2021.10.31 00:00:27.210 3: From the FHEM_GLOBALATTR environment: attr global logfile ./log/fhem-%Y-%m-%d.log
2021.10.31 00:00:27.211 3: From the FHEM_GLOBALATTR environment: attr global pidfilename ./log/fhem.pid
2021.10.31 00:00:27.211 3: From the FHEM_GLOBALATTR environment: attr global updateInBackground 1
2021.10.31 00:00:27.211 3: From the FHEM_GLOBALATTR environment: attr global nofork 0
2021.10.31 00:00:27.211 1: Messages collected while initializing FHEM:SecurityCheck:
  WEB is not password protected
  telnetPort is not password protected
...

Spannend ist wahrscheinlich nur die erste Message. Der Rest wiederholt sich eh

[Beta-User]

...vermutlich...

Vielleicht dann doch eher so:

Code Auswählen Erweitern

if ( $comp eq 'NewDay' ) {
        my @dch = localtime($now + 86400 + 3600*((localtime($now))[8] - (localtime($now + 86400.))[8]));
        push @next,
          _timelocal_modern( 0, 0, 0, $dch[3], $dch[4], $dch[5]+1900. );
          #_timelocal_modern( 0, 0, 0, (localtime($now + 86400.))[3,4], (localtime($now + 86400.))[5]+1900. );
        next;
    }

[rob]

Schaut gut aus .
Test mit frischem System wiederholt. Zeitumstellung wieder abgewartet und beobachtet.
Umstellung auf 00:00 erfolgt unauffällig: WebIF bleibt stabil, CPU-Last bleibt low
Keine Auffälligkeiten im Log.

Test im laufenden System glashart wiederholt: keine Auffälligkeiten. Sehr geschmeidig.

VG
rob

[Beta-User]

Danke für die Geduld, dann hier wieder die kommentarbereinigte Vollversion.

[rob]

Ich bedanke mich und es hat mich kein bisschen Geduld gekostet 

Setze mir mal einen Merker für nä. Jahr  :

Code Auswählen Erweitern


define lookilooki at 2022-10-30T23:50:00 { Log 1, "... watch out for the groundhog https://www.youtube.com/watch?v=AjNE2N0SDzs" }


VG
rob

[Prof. Dr. Peter Henning]

So, ich habe mal weitgehend alle Änderungswünsche von loredo, CoolTux und anderen in das "offizielle" Modul eingebaut. Das war eine Masse Zeug, irgendwer war da ziemlich fleißig - und wenigstens ungefähr musste ich es verstehen.

Wird gerade eingecheckt und dann per Update verteilt. Eventuelle Fehler gehen erst einmal auf Eure Kappe 

LG

pah

[Beta-User]

 
https://svn.fhem.de/trac/changeset/25198/ war doch nicht übermäßig groß? (Und der vorherige Commit lief schon "ewig" ohne, dass es Beschwerden gegeben hätte).

Eventuelle Fehler gehen erst einmal auf Eure Kappe 

Falls sich jemand veranlaßt sieht, Beschwerden abzuliefern, dann gerne an meine Adresse .

Dank ausdrücklich an @rob für's Testen! (@rob: Falls du das Testsystem nochmal quälen wolltest... Es gibt da noch ein Vorschlag für statistics, der ebenfalls ungetestet ist: https://forum.fhem.de/index.php/topic,123815.msg1184079.html#msg1184079. Irgendwie habe ich da noch Bauchweh, was passiert, wenn jemand den dayChange um genau 2h (bzw. 3h) verschiebt, vielleicht sollte man dazu noch einen Hinweis in die commandref aufnehmen...)