Help! - Immer noch katastrophaler Zustand - Ideen gesucht

[Prof. Dr. Peter Henning]

Anfang Januar habe ich meine beiden Produktivsysteme (Mikro-PC BeeOne) von Ubuntu 22.04 LTS auf Ubuntu 24.04 LTS upgedated.

Das Update lief auf beiden Kisten problemlos durch - und auch das FHEM-System läuft auf einer der beiden problemlos.

Auf dem zweiten Server gab aber es gleich zu Beginn eine irre Schwierigkeit: Plötzlich lieferten fast alle Perl-Subroutinen aus allen Modulen Zahlenwerte mit DEZIMALKOMMA statt Dezimalpunkt zurück. Die angezeigten locales auf beiden Systemen waren absolut identisch, siehe hier: https://forum.fhem.de/index.php?topic=140264.0

Ich habe hin- und her probiert, und schließlich durch Neu-Generierung der locales die Symptome beseitigt. Den Grund habe ich nicht gefunden.

Auf dem problematischen zweiten System lief FHEM nun drei Wochen durch - wurde aber immer zäher. Zwischen dem Absetzen von Kommandos, welche die HttpUtils benutzen, und der Ausführung kam es zu merkbaren Verzögerungen.

Vor ein paar Tagen hat sich meine FritzBox automatisch auf Software-Version 8.0 upgedated. Seitdem ist die Hölle los: Die die Netzwerklatenz wuchs immer weiter an, bis zu vier Minuten (!) Verzögerung. Und wohlgemerkt: Nichts im Log, außer Timeouts.

Ich hatte zunächst die Fritzbox im Verdacht, das hat sich nicht bestätigt. Mein nächster Verdächtiger war der Mosquitto-Server, also habe ich den temporär durch einen MQTT2-Server ersetzt.

Dabei kam es zu etlichen ungeplanten FHEM-Neustarts. Und plötzlich ist das dumme Komma-Problem wieder da.

Nach einem FHEM-Neustart werden für kurze Zeit - geschätzt 10 Sekunden - alle Zahlenwerte richtig, also mit Dezimalpunkt angezeigt. Dann plötzlich werden in den Readings Zahlenwerte mit DEZIMALKOMMA angezeigt, und das FHEM-Systen versinkt ins Chaos.

Und noch einmal: Kein Hinweise im Log, aber eine Million Fehlermeldungen des Typs

2025.01.24 19:13:06 1: PERL WARNING: Argument "0,000" isn't numeric in numeric lt (<) at (eval 9859) line 4.

Wenn ich dann auf dem Server ein "locale-gen de_DE.UTF-8" ausführe, beseitigt das den Effekt - aber nur für eine Minute.
Was um Himmels Willen kann in FHEM für eine Änderung der locale sorgen?

Ich stehe vor einem Rätsel, und wäre für jede hilfreiche Idee dankbar.

LG

pah

P.S.: Der Vollständigkeit halber: Die locale auf beiden Servern ist

Code Auswählen Erweitern

LANG=de_DE.UTF-8
LANGUAGE=
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC=de_DE.UTF-8
LC_TIME=de_DE.UTF-8
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY=de_DE.UTF-8
LC_MESSAGES="de_DE.UTF-8"
LC_PAPER=de_DE.UTF-8
LC_NAME=de_DE.UTF-8
LC_ADDRESS=de_DE.UTF-8
LC_TELEPHONE=de_DE.UTF-8
LC_MEASUREMENT=de_DE.UTF-8
LC_IDENTIFICATION=de_DE.UTF-8
LC_ALL=

und im global-Device ist als Sprache DE eingestellt.

[Adimarantis]

Mal ins Blaue:
Pakete

Code Auswählen Erweitern

language-pack-de
language-pack-de-baseneu installieren?

Edit: Und das hier hab ich auch noch gefunden:
https://askubuntu.com/questions/770309/cannot-permanently-change-locale-on-16-04-server
Das klingt fast ein bisschen nach deinem Problem - der Artikel ist für Ubuntu 16 - aber jemand mit Ubuntu 24 Problemen hat darauf als Lösung für seine Probleme verwiesen

[Prof. Dr. Peter Henning]

Das mit der erzwungenen Neuinstallation der Language Packs ist eine gute Idee, die ich gleich mal durchgezogen habe.
Bisher wirkt es, das sind jetzt schon 2 Minuten. Wenn es das war, gebe ich Dir einen aus...

Den Artikel hatte ich auch schon auf meiner Liste, das hatte nichts geholfen - /etc/default/locale war komplett richtig gesetzt.

LG

pah

Edit, 2 Minuten später: Nein, leider gibt es nach 2 Minuten ordnungsgemäßer Arbeit wieder überall Kommas...

[Bartimaus]

Nabend,

hast Du nach dem Update der FritzBox diese mal komplett stromlos für mind. 10s gemacht ?
Wirkt manchmal Wunder.

Aus wenn es jetzt nicht direkt hilft, hast Du mal dran gedacht, auf dem MiniPC als Basis "ProxMox" zu installieren ? Und dann z.B. FHEM als LXC. https://community-scripts.github.io/ProxmoxVE/scripts?id=fhem

Ich in vor einem Jahr auf Proxmox umgestiegen, und es lief alles noch nie so stabil wie seitdem. Das Handling von Backups ist sowas von easy...

[RalfRog]

meine beiden Produktivsysteme (Mikro-PC BeeOne)

Je nachdem wie ausgeprägt der Ehrgeiz ist den Fehler zu finden...   wäre clonen des lauffähigen Systems ne praktikable Lösung?

Gruß Ralf

[Prof. Dr. Peter Henning]

@Bartimaus: Gut gemeinte Vorschläge, die aber das Problem nicht lösen. Dass die FritzBox für das locale-Problem verantwortlich ist, wage ich zu bezweifeln.

@RalfRog: Hatte ich auch schon erwogen, ist aber viel Arbeit. Ich habe immer noch die Hoffnung, mit irgendeinem Konfigurationseingriff diese verfluchten Kommas loszuwerden.

LG

pah

[Bartimaus]

Vor ein paar Tagen hat sich meine FritzBox automatisch auf Software-Version 8.0 upgedated. Seitdem ist die Hölle los: Die die Netzwerklatenz wuchs immer weiter an, bis zu vier Minuten (!) Verzögerung. Und wohlgemerkt: Nichts im Log, außer Timeouts.

Moin,

ich bezog mich auch eher auf dieses Problem. Wenn das Netzwerk bei mir "ruckelte" ohne sichtbaren Fehler, war meist die Fritte schuld. Dann half nur noch ein richtiger Reboot, also Power hard off.

[Prof. Dr. Peter Henning]

So, das locale-Problem ist für den Moment weg. Was habe ich gemacht:

Code Auswählen Erweitern

localectl set-locale LANG=de_DE.UTF-8
dpkg-reconfigure locales
dpkg-reconfigure keyboard-configuration
Letzteres hat zur Neu-Zusammenstellung der initrd geführt.

Code Auswählen Erweitern

localedef -i de_DE -c -f UTF-8 de_DE.UTF-8
reboot

Zur Ursachenanalyse: Irgendetwas hat vorgestern offenbar eine Einstellung bei den locales zerschossen. Als ich versucht habe, das System zu stabilisieren, habe ich natürlich auch das Linux auf den allerneuesten Stand gebracht. Dabei ist offenbar die inkonsistente locale mit in die neu erzeugte initrd aufgenommen worden. Und natürlich dann bei jedem boot-Vorgang wieder inkonsistent geworden.

Mal sehen, ob das jetzt eine dauerhafte Lösung ist.

Jetzt ist nur noch die Frage der Netzwerklatenz offen. Seit ich den Mosquitto gestoppt und durch einen MQTT2-Server ersetzt habe, ist das nicht mehr aufgetreten. Das ist natürlich keine Lösung, aber im Moment ein Workaround.

Erstmal abwarten, ob die locale jetzt stabil bleibt.

Danke für die Denkansätze.

LG

pah

[Wernieman]

Mal eine Blöde Frage ... wie sieht es mit der Gesundheit der SSD und des Dateisystem aus?
i/o-Probleme im kern.log?

Hatte mal einen Server mit sehr komischen Problemen, u.A. auch Netzwerk, und das war u.A. die HDD bzw. Plattensubsystem (Controller), ist aber schon eine Ewigkeit (>5 Jahre?) her ...

Ist aber auf die schnelle nur ein Schnellschuß .....

[Prof. Dr. Peter Henning]

Zwischenbericht: Seit heute morgen läuft das System stabil - weder treten die locale-Probleme auf, noch Netzwerklatenzen.

Einziger negativer Effekt sind noch massenhafte Warnungen, weil in den Logfiles von heute noch diverse Zahlenwerte mit Komma auftreten. In den Monatslogs habe ich diese durch Dezimalpunkte ersetzt, bei den Tageslogs sollte morgen alles wieder in Butter sein.

Mal eine Blöde Frage ... wie sieht es mit der Gesundheit der SSD und des Dateisystem aus?
i/o-Probleme im kern.log?

Keine Meldungen, keine Ausfälle. Keine Probleme, alles in Butter.

LG

pah

[Wernieman]

Ist jetz etwas "stochern" im Nebel:

Wie viele perl-Versionen sind auf dem System?

Und .. ist das System aufgeräumt? Also wirklich alle "alte" entfernt

Stichworte:
apt-get autoremove --purge

Code Auswählen Erweitern

apt-get autoremove --purge
apt-get purge $(dpkg --get-selections | grep deinstall | cut -f1 | xargs)

Hinweis: da purge wirklich aufräumen, kann es natürlich zum GAU führen ... das dürfte Dir bekannt sein (und diese Bemerkung ist eher für andere gedacht, die den Thread finden und ohne Analyse c&p ausprobieren)

[Prof. Dr. Peter Henning]

Wie viele perl-Versionen sind auf dem System?

Natürlich nur eine, 5.38.2

Und .. ist das System aufgeräumt? Also wirklich alle "alte" entfernt

Auch das.

LG

pah

[Wernieman]

Verstehe mich bitte nicht falsch, aber bist Du Dir mit der perl-Version sicher?

Schließlich muß irgendetwas beim update schief gelaufen sein. z.B. könntest Du die Perl-Version, mit der FHEM läuft, prüfen (z.B. mit fheminfo) ...

Sorry mache gerade BainStorming

Edit:
Was mir gerade auf die schnelle einfällt ... hast Du Module per CPAN installiert??

[Prof. Dr. Peter Henning]

Ganz sicher.

Auf solche Fehler habe ich zuerst geprüft.

LG

pah

[Wernieman]

So im Moment, aus der Ferne, fällt mir nichts mehr ein .... außer eines:
Unter dem User fhem, hast Du da mal die locals geprüft? Schließlich kann man es auch Userbezogen setzen ....

[Prof. Dr. Peter Henning]

Auch das. Wie gesagt: Durch die letzte Aktion ist es jetzt behoben.

LG

pah

[Wernieman]

Ups .. Sorry, das habe ich überlesen. Hatte die ganze Zeit gerätselt, woran es liegen könnte und fühlte mich schon in meiner Berufsehre gekränkt 

[Prof. Dr. Peter Henning]

Ich habe ja genauso gerätselt - und der genaue Grund ist immer noch unklar. Echt irre war, dass eine einfache Neugenerierung der locale für ein paar Minuten wirkte.

Das führt zu Selbstzweifeln...

LG

pah

[Prof. Dr. Peter Henning]

So, der Übeltäter ist zumindest identifiziert.

Ich habe meinen VW ID7 über MQTT angekoppelt. Die Kiste sendet - wenn ihr mal danach ist - eine Menge Daten. Aus irgendeinem Grund aber verstopfen diese den MQTT-Server. Und zwar unabhängig davon, ob ich das als einen FHEM-internen MQTT-Server betreibe, oder extern als Mosquitto.

Jeweils nach ein paar Tagen geht gar nichts mehr, CPU-Last durch FHEM auf rund 100%.

Ich wechsele jetzt mal in des MQTT-Unterforum, wenn es eine Lösung gibt, werde ich die hier posten.

LG

pah