chrony 文档警告
警告:某些软件会受到系统时间中此类跳跃的严重影响。(这就是 chronyd 正常使用回转的原因。)文档
但是文档没有给出示例。将受到严重影响的软件示例有哪些?操作系统或任何后台进程是否存在风险?
我有两个联网的 voxls,我正在尝试使用 chrony 进行同步。voxls 以截然不同的系统时间启动,就像相隔数年一样。我希望 chrony 在服务开始使用时同步时间makestep
,但在启动 chrony 后,我仍然观察到系统时间有很大差异。
配置如下:
#server 10.0.0.102
makestep 1.0 3
driftfile /var/lib/chrony/drift
rtcsync
allow 10.0.0
local stratum 8
manual
logdir /var/log/chrony
#client 10.0.0.101
server 10.0.0.102 iburst maxpoll 5 prefer
makestep 1.0 3
driftfile /var/lib/chrony/drift
rtcsync
logdir /var/log/chrony
当 chrony 启动时,我希望它能makestep
一口气同步客户端,我看到 systemclt 状态中的时间调整
root@voxl1:~# systemctl status chronyd
● chronyd.service - NTP client/server
Loaded: loaded (/lib/systemd/system/chronyd.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2023-02-01 21:34:52 UTC; 83 years 0 months ago
Process: 3086 ExecStart=/usr/sbin/chronyd $OPTIONS (code=exited, status=0/SUCCESS)
Main PID: 3088 (chronyd)
CGroup: /system.slice/chronyd.service
└─3088 /usr/sbin/chronyd
Feb 01 21:34:52 voxl1 systemd[1]: Starting NTP client/server...
Feb 01 21:34:52 voxl1 chronyd[3088]: chronyd version 2.4 starting (+CMDMON +NTP +REFCLOCK +RTC -PRIVDROP -...EBUG)
Feb 01 21:34:52 voxl1 chronyd[3088]: Frequency -0.681 +/- 0.232 ppm read from /var/lib/chrony/drift
Feb 01 21:34:52 voxl1 systemd[1]: Started NTP client/server.
Feb 01 21:34:56 voxl1 chronyd[3088]: Selected source 10.0.0.102
Feb 01 21:34:56 voxl1 chronyd[3088]: System clock wrong by 2619696428.415401 seconds, adjustment started
Feb 07 11:02:04 voxl1 chronyd[3088]: System clock was stepped by 2619696428.415401 seconds
如果我使用chronyc tracking
orchronyc sources
观察时间偏移,报告表明时间在 100 微秒内同步。
root@voxl1:~# chronyc tracking
Reference ID : 10.0.0.102 (10.0.0.102)
Stratum : 9
Ref time (UTC) : Sun Feb 07 11:08:34 2106
System time : 0.000066503 seconds slow of NTP time
Last offset : -0.000076736 seconds
RMS offset : 0.000044063 seconds
Frequency : 0.785 ppm slow
Residual freq : -0.216 ppm
Skew : 0.987 ppm
Root delay : 0.004293 seconds
Root dispersion : 0.000069 seconds
Update interval : 129.8 seconds
Leap status : Normal
root@voxl1:~# chronyc sources -v
210 Number of sources = 1
.-- Source mode '^' = server, '=' = peer, '#' = local clock.
/ .- Source state '*' = current synced, '+' = combined , '-' = not combined,
| / '?' = unreachable, 'x' = time may be in error, '~' = time too variable.
|| .- xxxx [ yyyy ] +/- zzzz
|| Reachability register (octal) -. | xxxx = adjusted offset,
|| Log2(Polling interval) --. | | yyyy = measured offset,
|| \ | | zzzz = estimated error.
|| | | \
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^* 10.0.0.102 8 6 377 46 -77us[ -109us] +/- 1953us
但是,如果我然后打印日期,它根本不匹配时间服务器。
客户端 10.0.0.101
root@voxl1:~# date
Sun Feb 7 11:12:00 UTC 2106
服务器 10.0.0.102
root@voxl2:~# date
Thu Jan 1 04:43:02 UTC 1970
然后我试图触发一个手册chronyc makestep
,但这似乎也没有效果。
为什么我的日期不一样?makestep 是否按预期工作?chronyc makestep
时钟走多远有限制吗?
编辑:我有一个假设,但我不知道如何检验它。我想我可能会看到下溢错误。1970 年 1 月 1 日是 Unix 纪元。我的假设是当 chrony 第一次尝试在启动时同步客户端时,它会产生下溢错误,我看到了 systemctl 消息
Feb 01 21:34:56 voxl1 chronyd[3088]: System clock wrong by 2619696428.415401 seconds, adjustment started
Feb 07 11:02:04 voxl1 chronyd[3088]: System clock was stepped by 2619696428.415401 seconds
那个不正确的步骤将客户端推送到 2106,chrony 现在认为它与服务器同步,这就是为什么进一步的 makesteps 没有效果并且偏移量看起来很小的原因。
任何想法如何检验这个假设?
我有一个要同步的隔离和气隙 LAN。我有一台主机,它将成为 LAN 上所有客户端的权威时间服务器。LAN时间反映实时并不重要,重要的是所有客户端都同意时间。所有主机都运行 Linux。
我曾希望配置chronyd
它使用指定主机上的 RTC 作为权威时间源,并为客户端提供 NTP 服务,以便他们可以与之同步。因此,如果管理员需要更改 LAN 上的时间,他们可以更新时间服务器上的 RTC,只要有足够的时间,一切都会同步。
不幸的是,我chronyd
以这种方式配置的运气并不好。如果我没有指定任何时间服务器(“ server ...
” in /etc/chrony/chrony.conf
)然后chronyd
似乎没有源运行,而不是使用本地 RTC 作为源。
config 参数可refclock
用于选择外部时间源,例如 GPS 或 PPS,但似乎没有一个驱动程序适合读取 RTC。
我的一个想法是编写一个小型应用程序来读取 RTC 并将其作为 PPS 数据通过SOCK
驱动程序提供,但进一步阅读表明这也需要 NTP 源,因为它是亚秒级测量而不是绝对时间。
可以这样使用chronyd
吗?
我有一个机器人,正在使用 timemaster 启动 chrony 并从我的 GPS 添加 PTP 源。当我在无法获得卫星定位的内部启动机器人时,GPS 声称它是 1980 年 1 月 5 日。结果,我得到了一个被选中的第 0 层源,时间步进到 1980 年(因为我有“makestep 1 3”配置为chrony),然后当我将机器人带到外面并且GPS开始发布正确的时间时,它开始向2021倾斜,它当然永远不会到达。例如,chrony 源列表如下所示:
[root@robot user]# chronyc sources
210 Number of sources = 5
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
#x PTP0 0 2 377 4 +15173d[+15173d] +/- 8760us
^* ipv4.ntp1.rbauman.com 2 6 377 38 -43ms[ -15ms] +/- 134ms
^- 150.136.0.232 2 7 377 148 -59ms[ -31ms] +/- 192ms
^+ 38.229.58.9 2 8 377 216 +30ms[ +55ms] +/- 124ms
^+ ntp.speculation.org 2 7 377 38 -5919us[ +22ms] +/- 130ms
我在捕获此数据时设置了正确的时间,因此您可以看到第一个源关闭了 15,173 天,因为 2021 - 1980 = 15000 天。
我们使用的简单而明显的解决方法是关闭所有东西,然后在我们外出后重新打开,但我希望有一个我缺少的 chrony 配置选项(或 timemaster 配置选项)会忽略源(即使他们声称是第 0 层)如果它在 20 年或其他一些如此巨大的时间内关闭。
我曾尝试更改 makestep 设置,但这实际上会使问题变得更糟,因为如果我们禁用 makestep,有人在里面的机器人上工作几个小时,时钟会向 1980 倾斜几个小时,然后时钟会出错,直到它可以在相同的时间内向后倾斜。
感谢您的任何想法。我实际上是在运行不同操作系统的三台嵌入式 PC 上执行此操作,因此我无法指定 Linux 版本或 chrony 版本。如果您有一个仅适用于最新版本 chrony 的修复程序,我很高兴听到它!
我的任务是重建一个 LAN 服务器,该服务器用作数百台客户端计算机的 NTP 服务器。不幸的是,它在虚拟机上,正如在虚拟机中运行 NTP 服务器的限制是什么之类的问题所证明的那样?这远非理想。
但是,在当前情况下,这是我必须使用的,直到依赖此服务器的数百台机器在未来某个地方被重新配置为更强大的 NTP 设置。
幸运的是,客户端不依赖毫秒精度。我一直计划在新服务器上运行 Chrony,将其配置为使用四个本地第 2 层服务器。
我是 NTP 服务的新手,也是 Chrony 的新手。对于这种情况,您认为哪些服务器端设置必不可少?考虑到首先在虚拟机上运行 NTP 服务器的基本限制,目标是最大限度地减少不准确性。
# timedatectl
输出
Local time: Tue 2020-10-06 13:35:31 PDT
Universal time: Tue 2020-10-06 20:35:31 UTC
RTC time: Tue 2020-10-06 20:35:30
Time zone: America/Los_Angeles (PDT, -0700)
System clock synchronized: no
NTP service: active
RTC in local TZ: no
/etc/chrony.conf
是 RHEL 8 中的默认值(带有预配置的池)。
# chronyc sources
输出
210 Number of sources = 8
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^? excalibur.prolixium.com 0 9 0 - +0ns[ +0ns] +/- 0ns
^? paladin.latt.net 0 9 0 - +0ns[ +0ns] +/- 0ns
^? ronin.ruselabs.com 0 9 0 - +0ns[ +0ns] +/- 0ns
^? 2a00:7600::41 0 9 0 - +0ns[ +0ns] +/- 0ns
^? 50-205-244-112-static.hf> 0 9 0 - +0ns[ +0ns] +/- 0ns
^? time.cloudflare.com 0 9 0 - +0ns[ +0ns] +/- 0ns
^? 69.10.161.7 0 9 0 - +0ns[ +0ns] +/- 0ns
^? ntp3.your.org 0 9 0 - +0ns[ +0ns] +/- 0ns
# systemctl status chronyd
显示active (running)
,并且日志中没有错误。
显示的系统时间是正确的。
那么,鉴于所有这些事实,为什么我会看到System clock synchronized: no
?我如何把它变成yes
?
我有一个 Debian 10 系统,用于chronyd
保持时钟同步。配置非常简单:
pool 2.debian.pool.ntp.org offline iburst
bindaddress ::1
bindaddress 127.0.0.1
bindcmdaddress 127.0.0.1
allow 127
deny
keyfile /etc/chrony/chrony.keys
driftfile /var/lib/chrony/chrony.drift
logdir /var/log/chrony
log tracking measurements statistics
maxupdateskew 100.0
directive.
hwclockfile /etc/adjtime
rtcsync
makestep 1 3
它很高兴同步:
# chronyc sources
210 Number of sources = 4
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^- time.panq.nl 2 6 0 83h -1247us[-1191us] +/- 26ms
^* time.cloudflare.com 3 6 0 83h +1343ns[ +58us] +/- 2669us
^- metronoom.dmz.cs.uu.nl 2 6 0 83h -63us[ -63us] +/- 25ms
^- . 3 6 0 83h +2171us[+2171us] +/- 64ms
然而,“根差”却在稳步上升。从什么是 NTP 分散以及如何控制它?这似乎是上游服务器时钟最大误差的量度。它的上升非常缓慢,这个过程已经持续了大约 70 个小时左右,它处于 22.5 秒。我确实从经验中知道,这将继续上升,直到chronyd
重新启动。
# chronyc tracking
Reference ID : E1FE1EBE (time.cloudflare.com)
Stratum : 4
Ref time (UTC) : Sun Jan 26 23:19:16 2020
System time : 0.000000005 seconds fast of NTP time
Last offset : +0.000056495 seconds
RMS offset : 0.000056495 seconds
Frequency : 79.909 ppm slow
Residual freq : +17.510 ppm
Skew : 56.420 ppm
Root delay : 0.004632703 seconds
Root dispersion : 22.573289871 seconds
Update interval : 1.6 seconds
Leap status : Normal
这对我来说似乎很不寻常。我有许多其他系统与 Stratum 1 服务器同步时间,其中根分散度低且恒定。我认为我在配置上没有做任何奇怪的事情,并且“上游时钟中的最大误差”稳步上升的想法闻起来有点不对劲。
这是正常的吗?