[Eisfair] Zeit-Synchronisation auf Windows schlägt (meistens) fehl

Mo Apr 7 00:00:34 CEST 2025

Hallo!

Ein Problem nagt schon lange an mir und jetzt will ich das endlich mal 
angehen:

Mein eisfair bezieht seine Systemzeit offenbar durch zwei Pakete: NTP 
Service und netdate. Warum auch immer. Jedenfalls ist die Uhrzeit 
eigentlich immer korrekt.

Aber meine Windows10-Clients haben ein Problem. Entweder ich stelle dort 
meine Zeit manuell ein (und korrigiere sie entsprechend auch immer 
wieder manuell) oder ich habe "automatisch festlegen" eingestellt. In 
diesem Fall ist fest mein Eisfair-Server als Quelle eingestellt. Ich 
vermute, via DHCP verteilt. Aber dieser Abgleich geht vielleicht 1/1000 
mal. Aktuell steht da "zuletzt erfolgreich: 14.6.2024(sic!)". Wenn ich 
auf "jetzt synchronisieren" klicke, dann läuft es sich tot und bricht ab.

Was kann denn da schief laufen?

Das Logfile vom ntp service sagt beim Start:

  6 Apr 23:55:51 ntpd[14611]: ntpd 4.2.8p15 at 1.3728-o Fri Dec 25 15:02:35 
UTC 2020 (1): Starting 

│ 6 Apr 23:55:51 ntpd[14611]: Command line: /usr/sbin/ntpd -u ntp:ntp -c 
/etc/ntp.conf -l /var/log/ntp.log -p /var/run/ntpd.pid 

│ 6 Apr 23:55:51 ntpd[14611]: 
---------------------------------------------------- 

│ 6 Apr 23:55:51 ntpd[14611]: ntp-4 is maintained by Network Time 
Foundation, 

│ 6 Apr 23:55:51 ntpd[14611]: Inc. (NTF), a non-profit 501(c)(3) 
public-benefit 

│ 6 Apr 23:55:51 ntpd[14611]: corporation.  Support and training for 
ntp-4 are 

│ 6 Apr 23:55:51 ntpd[14611]: available at 
https://www.nwtime.org/support 

│ 6 Apr 23:55:51 ntpd[14611]: 
---------------------------------------------------- 

│ 6 Apr 23:55:51 ntpd[14613]: proto: precision = 0.516 usec (-21) 

│ 6 Apr 23:55:51 ntpd[14613]: basedate set to 2020-12-13 

│ 6 Apr 23:55:51 ntpd[14613]: gps base set to 2020-12-13 (week 2136) 

│ 6 Apr 23:55:51 ntpd[14613]: leapsecond file 
('/var/lib/ntp/ntp.leapseconds'): good hash signature 

│ 6 Apr 23:55:51 ntpd[14613]: leapsecond file 
('/var/lib/ntp/ntp.leapseconds'): loaded, expire=2025-12-28T00:00:00Z 
last=2017-01-01T00:00:00Z ofs=37 

│ 6 Apr 23:55:51 ntpd[14613]: 0.0.0.0 c01e 0e TAI 37 leap 201701010000 
expires 202512280000 

│ 6 Apr 23:55:51 ntpd[14613]: Listen and drop on 0 v6wildcard [::]:123 

│ 6 Apr 23:55:51 ntpd[14613]: Listen and drop on 1 v4wildcard 
0.0.0.0:123 

│ 6 Apr 23:55:51 ntpd[14613]: Listen normally on 2 lo 127.0.0.1:123 

│ 6 Apr 23:55:51 ntpd[14613]: Listen normally on 3 lan0 192.168.10.1:123 

│ 6 Apr 23:55:51 ntpd[14613]: Listen normally on 4 lan0:1 
192.168.0.2:123 

│ 6 Apr 23:55:51 ntpd[14613]: Listen normally on 5 lo [::1]:123 

│ 6 Apr 23:55:51 ntpd[14613]: Listen normally on 6 lan0 
[2a02:8109:8402:1d00:c24a:ff:fe03:605]:123 

│ 6 Apr 23:55:51 ntpd[14613]: Listen normally on 7 lan0 
[fe80::c24a:ff:fe03:605%2]:123 

│ 6 Apr 23:55:51 ntpd[14613]: Listening on routing socket on fd #24 for 
interface updates 

│ 6 Apr 23:55:51 ntpd[14613]: kernel reports TIME_ERROR: 0x2041: Clock 
Unsynchronized 

│ 6 Apr 23:55:51 ntpd[14613]: 0.0.0.0 c01d 0d kern kernel time sync 
enabled 

│ 6 Apr 23:55:51 ntpd[14613]: kernel reports TIME_ERROR: 0x2041: Clock 
Unsynchronized 

│ 6 Apr 23:55:51 ntpd[14613]: 0.0.0.0 c012 02 freq_set kernel 19.219 PPM 

│ 6 Apr 23:55:51 ntpd[14613]: 0.0.0.0 c016 06 restart 

│ 6 Apr 23:55:51 ntpd[14613]: DNS time.fu-berlin.de -> 130.133.1.10 

│ 6 Apr 23:55:51 ntpd[14613]: DNS de.pool.ntp.org -> 217.160.19.219 

│ 6 Apr 23:55:51 ntpd[14613]: DNS ntp1.ptb.de -> 2001:638:610:be01::108 

Wenn ich Set Time via ... auswähle:

Try to set Time via ntp1.ptb.de ...
  6 Apr 23:56:56 ntpdate[17431]: the NTP socket is in use, exiting
Try to set Time via time.fu-berlin.de ...
  6 Apr 23:56:56 ntpdate[17436]: the NTP socket is in use, exiting
Try to set Time via de.pool.ntp.org ...
  6 Apr 23:56:56 ntpdate[17441]: the NTP socket is in use, exiting

Hardware Clock Time is now ...
2025-04-06 21:56:57.507845+02:00
Software Clock Time is now ...
Sun Apr  6 23:56:58 CEST 2025