a_g*_*est 38 ntpd ntp systemd-timesyncd
当我查询 NTP 守护进程的状态时,ntpdc -c sysinfo我得到以下输出:
system peer: 0.0.0.0
system peer mode: unspec
leap indicator: 11
stratum: 16
precision: -20
root distance: 0.00000 s
root dispersion: 12.77106 s
reference ID: [73.78.73.84]
reference time: 00000000.00000000 Thu, Feb 7 2036 7:28:16.000
system flags: auth monitor ntp kernel stats
jitter: 0.000000 s
stability: 0.000 ppm
broadcastdelay: 0.000000 s
authdelay: 0.000000 s
Run Code Online (Sandbox Code Playgroud)
这表示 NTP 同步失败。但是系统时间精确到 1 秒精度。当我在没有网络连接的情况下运行我的系统时,系统时间会偏离大约 10 秒。
这种行为表明系统有另一种同步时间的方式。我意识到还有systemd-timesyncd.service(配置文件位于/etc/systemd/timesyncd.conf)并timedatectl status给了我正确的时间:
Local time: Thu 2016-08-25 10:55:23 CEST
Universal time: Thu 2016-08-25 08:55:23 UTC
RTC time: Thu 2016-08-25 08:55:22
Time zone: Europe/Berlin (CEST, +0200)
NTP enabled: yes
NTP synchronized: yes
RTC in local TZ: no
DST active: yes
Last DST change: DST began at
Sun 2016-03-27 01:59:59 CET
Sun 2016-03-27 03:00:00 CEST
Next DST change: DST ends (the clock jumps one hour backwards) at
Sun 2016-10-30 02:59:59 CEST
Sun 2016-10-30 02:00:00 CET
Run Code Online (Sandbox Code Playgroud)
所以我的问题是这两种机制有什么区别?其中之一是否已弃用?它们可以并行使用吗?当我想查询 NTP 同步状态时,我应该信任哪一个?
(请注意,我有一个不同的系统(在不同的网络中),这两种方法都表明成功并产生正确的时间。)
max*_*axf 29
systemd-timesyncd 基本上是一个小型的仅限客户端的 NTP 实现,或多或少与较新的 systemd 版本捆绑在一起。它比完整的 ntpd 更轻量级,但仅支持时间同步 - 即它不能充当其他机器的 NTP 服务器。它旨在为客户端替换 ntpd。
您不应该同时使用两者,因为理论上它们可以选择不同的时间服务器,它们之间有轻微的延迟,导致您的系统时钟周期性地“跳跃”。
要获得状态,不幸的是,ntpdc如果您使用 ntpd 和timedatectltimesyncd,则需要使用,我知道没有可以读取两者的实用程序。
小智 28
systemd-timesyncd 没有时钟纪律:时钟没有经过训练或补偿,内部时钟随时间的漂移也没有减少。它具有调整轮询间隔的基本逻辑,但如果不规范主机,则由于 systemd-timesyncd 以它认为近期漂移所需的任何间隔推送或拉动,因此主机将永远以不均匀的时间结束。它也无法评估远程时间源的质量。您不太可能获得远大于 100 毫秒的准确度。这对于笔记本电脑等简单的最终用户设备来说已经足够了,但对于需要更高时间精度的分布式系统来说,这肯定会导致问题。