Telegram Meldung ignoriert, Uhrzeit falsch?

[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