FHEM resetiert sich wegen Zugriff auf DWD Modul nach Update

Begonnen von laufhem, 21 Juli 2022, 14:50:28

Vorheriges Thema - Nächstes Thema

Beta-User

Zitat von: Otto123 am 25 Juli 2022, 10:53:13
die Meldung kommt mMn vom Modul /Time/Piece.pm - dies wird offenbar mit leeren Day aufgerufen - warum kann ich nicht nachvollziehen. Müsste man suchen was da genau passiert...
@Beta-User gibts ähnliche Meldungen im Forum? Mir ist nichts aufgefallen.
Mir wäre nichts bekannt. Das Modul selbst verwendet daraus localtime und gmtime, was an sich auch nicht problematisch sein dürfte. "stacktrace" zu aktivieren könnte helfen rauszufinden, von wo aus die Funktion (_mktime() in Time:Piece.pm) aufgerufen wird. Komisch ist da allerdings, dass gar kein Zeitstempel geschrieben wird. Ist FHEM da schon tot?!?

Die Fehlermeldung unmittelbar vorher ist mAn. auch unproblematisch, das ist die Anwort aus einem BlockingCall mit 60 Sek. timeout.

Jedenfalls sind beides nur Warnhinweise und eben gerade (nach meiner Interpretation) keine (für sich genommen) wirklich kritischen Meldungen.
Von daher bleibt mir nur die Spekulation, dass insgesamt zu viele forks (aus BlockingCall) da sein könnten und FHEM zu träge reagiert (aus systemd-Sicht).

Zitat von: frank am 25 Juli 2022, 10:54:23
theoretisch könnten auch die gelieferten daten "fehlerhaft" oder neu strukturiert sein.
Möglich wäre es, allerdings kann ich im Moment keinen Zusammenhang zwischen fehlerhaften Daten und dieser Funktion in Time::Piece.pm herstellen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors