Stephan Manske
2025-04-06 22:00:34 UTC
Antworten
PermalinkEin 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 ***@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