Telegram Meldung ignoriert, Uhrzeit falsch?

[AtomicIX]

@homoran sagte in Telegram Meldung ignoriert, Uhrzeit falsch?:

1738412580

Ich bekomme das einfach nicht hin.
Egal ob auf dem System im Garten, das jetzt lange Zeit ohne Probleme lief, sowohl auch das relativ neue System 2 Monate alt, das hier zuhause steht, laufen nicht mit dem Bot und Commandos.
Die Zeit Sync soll wohl aus dem Hauptsystem von Proxmox kommen und dann an den LXC weitergereicht werden.

Ich habe echt keine Ahnung was/wie/warum das zusammen hängt.

Werde gleich mal iobroker auf nen Raspaberry installieren und gucken ob es da läuft.

Es gibt sonnst Telegram direkt übern Browser: https://web.telegram.org/ aber das geht scheinbar auch nicht mehr.

[BananaJoe]

@atomicix also wie @Homoran auch feststellen konnte sind da 42 Sekunden Abweichung.
Meistens ist bis 30 Sekunden Abweichung egal bzw. wird noch toleriert (ob das bei Telegram auch so ist weis sich nicht).

Beruflich muss ich mich auch um Zeit-Synchronität in den Netzen kümmern - wobei dabei wichtiger ist das alle die gleiche Zeit haben, auch wenn die vielleicht daneben liegt.

Also wäre ein Ansatz dafür zu sorgen das alle den gleichen Zeitserver nehmen.

Dein Host läuft mit Proxmox. Da gibt es diese Anleitung:
https://pve.proxmox.com/wiki/Time_Synchronization
Den Einträgen nach läuft da noch der "klassische" ntp.service

Bei mir ist in der Datei

/etc/chrony/chrony.conf

der Debian-Pool voreingestellt:

# Include configuration files found in /etc/chrony/conf.d.
confdir /etc/chrony/conf.d

# Use Debian vendor zone.
pool 2.debian.pool.ntp.org iburst

# Use time sources from DHCP.
sourcedir /run/chrony-dhcp

# Use NTP sources found in /etc/chrony/sources.d.
sourcedir /etc/chrony/sources.d

Die anderen Optionen greifen bei mir nicht, /etc/chrony/conf.d ist bis auf eine README leer, die IP des Proxmox ist fest eingestellt so das es das Verzeichnis /run/chrony-dhcp nicht gibt und /etc/chrony/sources.d ist auch leer bis auf die README.

Der benutzt bei mir also nur den Pool 2.debian.pool.ntp.org

Ok, nutzen wir eine gemeinsame Zeitquelle für alle Geräte. Das kann die FRITZ!Box sein oder z.B. meine Lieblinge zeit.fu-berlin.de und time.fu-berlin.de, siehe https://www.zedat.fu-berlin.de/Time-Service (ja, das sind 2 verschiedene Server)
Also ändern wir das in der Datei /etc/chrony/chrony.confwie folgt ab:

# Use Debian vendor zone.
#pool 2.debian.pool.ntp.org iburst
server zeit.fu-berlin.de iburst
server time.fu-berlin.de iburst

und den Dienst neu starten:

systemctl restart chronyd

und nach einiger Zeit prüfen ob das klappt:

root@proxmox01:~# journalctl --since -1h -u chrony
Feb 02 14:26:26 proxmox01 chronyd[1148]: chronyd exiting
Feb 02 14:26:26 proxmox01 systemd[1]: Stopping chrony.service - chrony, an NTP client/server...
Feb 02 14:26:26 proxmox01 systemd[1]: chrony.service: Deactivated successfully.
Feb 02 14:26:26 proxmox01 systemd[1]: Stopped chrony.service - chrony, an NTP client/server.
Feb 02 14:26:26 proxmox01 systemd[1]: Starting chrony.service - chrony, an NTP client/server...
Feb 02 14:26:26 proxmox01 chronyd[922074]: chronyd version 4.3 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +NTS +SECHASH +IPV6 -DEBUG)
Feb 02 14:26:26 proxmox01 chronyd[922074]: Frequency -40.622 +/- 0.028 ppm read from /var/lib/chrony/chrony.drift
Feb 02 14:26:26 proxmox01 chronyd[922074]: Using right/UTC timezone to obtain leap second data
Feb 02 14:26:26 proxmox01 chronyd[922074]: Loaded seccomp filter (level 1)
Feb 02 14:26:26 proxmox01 systemd[1]: Started chrony.service - chrony, an NTP client/server.
Feb 02 14:26:31 proxmox01 chronyd[922074]: Selected source 160.45.10.8 (zeit.fu-berlin.de)
Feb 02 14:26:31 proxmox01 chronyd[922074]: System clock TAI offset set to 37 seconds

Interessanterweise hatte ich wohl ein Offset von 37 Sekunden .....

So, nun noch die ioBroker VM (oder Container?).
Ein Container sollte die Zeit des Hosts übernehmen. Hier sollte also nichts zu tun sein. Außer das ggf. die richtige Zeitzone eingestellt werden muss.

timedatectl set-timezone Europe/Berlin

Wenn es eine VM ist, dann müsste man schauen welchen Zeitprovider diese benutzt.
Neuere System sollten den systemd-timesyncd.service nutzen, das prüfst du per

systemctl status systemd-timesyncd.service

Läuft der Dienst kannst du diese Datei bearbeiten:

nano /etc/systemd/timesyncd.conf

und setzt folgende 2 Einträge bzw. änderst die vorhandenen:

[Time]
NTP=zeit.fu-berlin.de
FallbackNTP=time.fu-berlin.de

Wichtig ist auch den Fallback zu setzen, der steht sonst auch auf einer Pool-Adresse
Dann den Dienst neu starten

systemctl restart systemd-timesyncd.service

und nach einer Weile prüfen:

timedatectl show-timesync

Wenn es den Dienst nicht gibt / der nicht läuft, prüfe ob der NTP läuft:

systemctl status ntp.service

ist der es, so bearbeite folgende Datei:

nano /etc/ntp.conf

Die Einträge sind wie auf dem Proxmox-Host,
also alle Zeilen die mit pool oder server anfangen, auskommentieren und nur diese beiden setzen:

server zeit.fu-berlin.de iburst
server time.fu-berlin.de iburst

Dann den Dienst neu starten:

systemctl restart ntp.service

und nach einer Weile mit

ntpq -p

prüfen.

Ggf. prüfst bei einem Container ob da nicht trotzdem etwas läuft.
Wie beschrieben hatte ich 37 Sekunden Abweichung meines Proxmox-Host ...

[BananaJoe]

Nachtrag: Also bei mir zu Hause ist alles was den Ubuntu-Pool, die FRITZ!Box oder die TU-Berlin Server nutzt im Millisekunden-Bereich auseinander.
Alle 3 Proxmox-Server aus dem Cluster (auch der eine der als VM unter VMware auf einem ESXi läuft), wichen um 37 Sekunden davon ab.
Die Proxmox-Backup-Appliance die auf dem ESXi läuft hatte die richtige Zeit.

Wobei ich bei meiner Recherche irgendwo meine gelesen zu haben das die Proxmox-System in einem Cluster peinlich genau ihre untereinander abstimmen weil es sonst Probleme gibt

[AtomicIX]

Das ist ja Wahnsinn was du da zusammen getragen hast. Vielen dank dafür.
Ich habe gestern Abend einen Raspi3 mit iobroker aufgesetzt und dort ein aktueller Backup eingespielt.
(Wusste gar nicht mehr, wie langsam son Rapsi ist )
Hat natürlich alles funktioniert, mit Telegram ect.
Also nachdem ich noch noch einiges an Zeit in einem Proxmox System gesteckt habe und damit auch gescheitert bin, habe ich auf meinem Test/Ersatzsystem ein sauberes Proxmox aufgesetzt und alles neu eingerichtet. Jetzt läuft alles.
Wenn ich jetzt die nächsten Tage in Garten komme, werde ich die Systeme tauschen und das fehlerhafte Gartensystem hier zuhause mal mit deinen Informationen füttern bzw. probieren woran es gelegen hat. Vielleicht komme ich ja mit deiner Anleitung weiter.
Da ich eh die NVE tauschen wollte, kann ich das jetzt umsetzten. Nach 3 Jahren 24/7 kann man das mal machen.
Also vielen dank @BananaJoe , ich werde die nächsten Tage berichten, was ich geworden bin.

[Thomas Braun]

@atomicix sagte in Telegram Meldung ignoriert, Uhrzeit falsch?:

(Wusste gar nicht mehr, wie langsam son Rapsi ist )

Der 3er ist mittlerweile mit seinem 1GB RAM zu klein. Die aktuellen Versionen 4&5 mit mehr RAM sind deutlich performanter.

[AtomicIX]

@bananajoe
nun habe ich es mal geschafft, die Systeme zu tauschen.
Habe mein Ersatzsystem mit neuer NVE und alles frisch aufgesetzt in Garten gepflanzt. Es ist sehr gut angewachsen .
Läuft alles super.
Nun habe ich also mein altes Gartensystem mit den Uhrzeit Fehler zuhause.
Habe es einmal alles frisch upgedatet, also das Proxmox/Linux System.
Nun läuft es wieder einwandfrei mit der Uhrzeit
Vielleicht hat sich beim letzten Update im Garten ( I-Net über Sim) vielleicht irgendetwas verschluckt, wobei mein relativ frisches Ersatzsystem (was ich ja jetzt noch mal neu gemacht habe und jetzt im Garten läuft) hier zuhause ja auch Probleme hatte.
Also es läuft, leider konnte ich jetzt keinen Fehler feststellen und muss es hinnehmen, das es wieder geht.

Ich bedanke mich jedenfalls für die Unterstützung.

[AtomicIX]

@thomas-braun
meine 2x Rpi4 mit 4Gb Ram hatte ich zur Kriese ( vor 2 Jahren oder so) für einen sehr guten Preis verkauft.
Habe ja eigentlich mit den 2 NUC's eine sehr gute alternative. Für kleine Bastelprojekte reichen mir die 3er noch.
War hat nur erschrocken, wie langsam das ist, im Gegensatz zum NUC Gen10 mit i7 und i3 und 32GB Ram

[BananaJoe]

@atomicix ich habe vor ein paar Monaten mal einen Pi 1 und Pi 2 mal wieder in Betrieb genommen ... die hatte ich früher als Eigenbau AccessPoint genutzt, und jetzt um ein Relais zu schalten. Habe es dann gelassen.

Nö, da ist man inzwischen verwöhnt ...

[Homoran]

@atomicix was sagt denn das System zum ntp?

[AtomicIX]

@homoran
Also im Proxmox Root System habe ich:

root@Proxmox:~# timedatectl status
               Local time: Wed 2025-02-05 15:05:15 CET
           Universal time: Wed 2025-02-05 14:05:15 UTC
                 RTC time: Wed 2025-02-05 14:05:15
                Time zone: Europe/Berlin (CET, +0100)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

und im LXC Container:

iobroker@ioBroker:~$ timedatectl status
               Local time: Mi 2025-02-05 15:07:04 CET
           Universal time: Mi 2025-02-05 14:07:04 UTC
                 RTC time: n/a
                Time zone: Europe/Berlin (CET, +0100)
System clock synchronized: yes
              NTP service: inactive
          RTC in local TZ: yes

So scheint es jedenfalls zu funktionieren.

[Homoran]

@atomicix sagte in Telegram Meldung ignoriert, Uhrzeit falsch?:

So scheint es jedenfalls zu funktionieren.

Noch!??

@atomicix sagte in Telegram Meldung ignoriert, Uhrzeit falsch?:

NTP service: inactive

bis die Zeiten wiedrr auseinander driften

[Thomas Braun]

@atomicix sagte in Telegram Meldung ignoriert, Uhrzeit falsch?:

  RTC in local TZ: no

und

  RTC in local TZ: yes

Da es aber nur eine RTC/RealTimeClock gibt sollten da auch die Einstellungen imho gleich sein.

[AtomicIX]

@homoran
Mein Fehler, das war das alte Garten System, das jetzt hier zuhause steht, das Livesystem im Garten hat:

               Local time: Mi 2025-02-05 15:12:25 CET
           Universal time: Mi 2025-02-05 14:12:25 UTC
                 RTC time: n/a
                Time zone: Europe/Berlin (CET, +0100)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: yes

[AtomicIX]

Ich brauche noch mal Hilfe.
Das Problem ist wieder da.
Ich habe gestern das Proxmox System neu gestartet und Telegram läuft wieder nicht.

In Proxmox habe ich:

                 RTC time: Wed 2025-02-19 14:53:03 UTC
                Time zone: Europe/Berlin (CET, +0100)
System clock synchronized: no
              NTP service: active
          RTC in local TZ: no

und im LXC

                 RTC time: n/a
                Time zone: Europe/Berlin (CET, +0100)
System clock synchronized: no
              NTP service: active
          RTC in local TZ: no

Das scheint aber auch nur im Garten zu sein. Zuhause läuft das alles.
Zuhause hängt der NUC über ein USB -> LAN Adapter direkt an meiner FB 6690
im Garten hängt der NUC direkt am LAN an einer FB 4060 und als Modem habe ich ein Zyxel FWA 505 5G Router.
Die 5060 ist aber der DNS im Netzwerk.
Vor meinem ganzen Umbau, als es sehr lange ohne Probleme lief, hatte ich eine FB 6850LTE.
Ich habe die Vermutung, das durch die Kombi FB und Zyxel vielleicht irgendetwas blockiert wird?
Kann ich das irgendwie prüfen?
Das aktuelle Proxmox System ist quasi auf Standard was die NTP/RTC Einstellung betrifft, was zuhause auch läuft.
Somit schien die Config ok zu sein.
Ich hatte ja am Anfang, als ich die Probleme hatte, schon einmal die alte 6850 wieder eingebaut und es lief auch nicht, aber vielleicht habe ich auch nicht lange genug gewartet?
Dazu kommt momentan ist es halt sehr kalt und ich habe jetzt nicht die Lust, Stunden im Garten zu sitzen und rum zu stochern um eine Lösung zu finden.
Über Remote komme ich nur auf den LXC vom iobroker und auf die FB, aber nicht auf das Proxmox System. Das war schon immer so und muss an der Mobilfunkverbindung liegen. Von daher würde ich mich über Ergebnisse freuen, die ich Vorort im Schrebergarten probieren kann.
Noch mal die alte 6850 verbauen und warten? Wie lange?

Über Unterstützung wäre ich sehr dankbar.

[BananaJoe]

Naja, NTP scheint an, synchronisiert aber nichts.
Da oben hatte ich eine längere Anleitung gepostet was man machen kann: https://forum.iobroker.net/post/1245092
Die vor eingestellten Debian-Zeitserver waren bei mir da auch Mist. Ist bei mir nur nicht aufgefallen weil ich nur Ubuntu und Windows-VMs habe, und die holen sich die Zeit separat von woanders - und nur beim Start die vom Virtualisierungshost

[AtomicIX]

So, bin heute mal 2h im Garten gewesen und habe Probiert.
Das System das zuhause ohne Probleme, funktioniert hat, als Sync und NTP/RTC alles gut, läuft im Garten nicht.

im Root System :

           RTC time: Wed 2025-02-20 15:58:03 UTC
                Time zone: Europe/Berlin (CET, +0100)
System clock synchronized: no
              NTP service: active
          RTC in local TZ: yes

im LXC:

           RTC time: n/a
                Time zone: Europe/Berlin (CET, +0100)
System clock synchronized: no
              NTP service: active
          RTC in local TZ: no

Das system aus dem Garten hier zuhause läuft hingegen Problemlos.
Also es scheint nicht an den Einstellungen vom Proxmox System zu liegen, sondern irgendwie mit der Fritzbox/Zyxel System
Ich hatte jetzt keine Lust mehr, weil kalt und die Gasflasche ist leer, noch die Fritzbox gegen die alte zu tauschen.
Müsste dann ja noch ne weile warten, um sicher zu sein, das auch alles Synchronisiert ist.

Hab ihr ne Idee, ob oder wie ich testen kann, ob es an der FB oder Sim Verbindung liegen kann?
Internet generell läuft echt super.
So langsam bin ich echt am verzweifeln.

[BananaJoe]

@atomicix was hast du denn Probiert?
So muss das auf dem Host aussehen:

root@proxmox01:~# timedatectl status
               Local time: Thu 2025-02-20 19:48:33 CET
           Universal time: Thu 2025-02-20 18:48:33 UTC
                 RTC time: Thu 2025-02-20 18:48:33
                Time zone: Europe/Berlin (CET, +0100)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Und so in der VM / Container (wobei der vermutlich die richtige zeit hat wenn der Host die hat):

root@piholepm:~# timedatectl status
               Local time: Do 2025-02-20 19:49:51 CET
           Universal time: Do 2025-02-20 18:49:51 UTC
                 RTC time: Do 2025-02-20 18:49:51
                Time zone: Europe/Berlin (CET, +0100)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no
root@piholepm:~#

man beachte die Zeile mit

...
System clock synchronized: yes
...

Wenn du Zeitserver aus dem Internet konfiguriert hast und diese für den Host erreichbar sind, ist alles andere egal.
Wobei die FRITZ!Boxen in der Regel auch die genaue Zeit liefern.

Darf ich noch mal auf meinen obigen Beitrag verweisen?

[AtomicIX]

@bananajoe danke für die Rückmeldung.
Ja auf den Beitrag darfst du verweisen. An den habe ich mich auch gehalten.
Zuhause habe ich dort die Synchronisation und RTC und NTP ist auf Yes. Also anders als bei dir, ist halt alles auf Yes. Sollte ja aber eigentlich ok sein, oder?
Im Garten läuft es halt nicht. Ich könnte alternativ mal probieren, wie du schon sagtest, die FB als Zeitserver nehmen, und nicht Berlin..., dann muss der Proxmox halt gar nicht raus aus dem Netz.

[BananaJoe]

@atomicix sagte in Telegram Meldung ignoriert, Uhrzeit falsch?:

Ich könnte alternativ mal probieren, wie du schon sagtest, die FB als Zeitserver nehmen, und nicht Berlin..., dann muss der Proxmox halt gar nicht raus aus dem Netz.

Du hast das vielleicht eingestellt - aber er macht es ja nicht
Dienste neu gestartet?

systemctl restart chronyd

Wenn es einen Offset gibt müsste im Log so etwas wie

Feb 02 14:26:26 proxmox01 systemd[1]: Started chrony.service - chrony, an NTP client/server.
Feb 02 14:26:31 proxmox01 chronyd[922074]: Selected source 160.45.10.8 (zeit.fu-berlin.de)
Feb 02 14:26:31 proxmox01 chronyd[922074]: System clock TAI offset set to 37 seconds

auftauchen (einmalig)

[AtomicIX]

Ja restart habe ich gemacht, habe auch das ganze System neu gestartet. Im Garten geht's nicht, zuhause ja.
Ich werde mir heute noch mal ne 2te Sim Karte besorgen und probieren das zuhause zu rekonstruieren. Ansonsten werde ich erts am Sonntag wieder im Garten probieren können