NTP · XB 现场笔记

分别检查 timesyncd 服务状态与时钟证据

Thu, 11 Mar 2027 00:00:00 +0000

systemd-timesyncd 是一个精简 SNTP 客户端，用配置的时间源同步本地系统时钟。它可以帮助证书检查与墙钟时间戳保持有意义，但不会无条件保证某个精度范围。守护进程能否运行、是否收到可接受样本，以及系统是否报告同步，是需要分别确认的事实。只看到安装了客户端，或者某条命令成功返回，都不足以推导时钟已经准确。

坏掉的样子

守护进程并不总是平滑校正。文档明确说明，大偏差会直接跳时，小偏差则逐渐调整。因此，开机时离正确时间很远的机器，可能发生时间不连续。经过时长测量应使用单调时钟，解释墙钟时间戳的应用则应处理校时，而不是假定时间永远平滑前进。不能把“精简客户端”误写成“绝不会让应用看见时间跳跃”。

FallbackNTP 不是显式服务器不可达时就一定会启用的通用应急列表，它在没有其他已知服务器信息时才适用。全局 NTP 条目和 networkd 提供的链路时间源，优先于这个后备设置。因此，应检查实际来源选择与配置覆盖文件，不能仅因为主来源连接失败，就断定某个写在 fallback 中的服务器必定已经被尝试。

未同步也不能证明 UDP 流量被阻止。服务可能缺失、未启用、被单元条件排除、没有调整时钟的权限，或者正在拒绝不合适样本。反过来，全局同步属性也不能单独说明哪个进程提供了时间。应区分管理器看到的服务状态、客户端观察到的样本，以及内核层同步指示，避免把来自不同层面的一个布尔值当成完整故障结论。

快速验证

这个失败模式实验在一次性 Debian 12 Docker 容器中以 root 运行，PID 1 为 systemd 252.39。初始化进程通过 /usr/bin/setpriv --bounding-set=-sys_time,-sys_module /sbin/init 启动，移除相关能力以防止调整 Docker 虚拟机共享时钟。脚本在请求任何服务启动前检查该前提，并要求安装包中的容器排除条件存在：

from pathlib import Path
import json,subprocess

def run(*args):
 result=subprocess.run(args,text=True,capture_output=True,timeout=10)
 assert result.returncode==0,(args,result.stderr)
 return result.stdout.strip()
def properties(unit):
 output=run('systemctl','show',unit,'-p','ActiveState','-p','SubState','-p','MainPID','-p','ConditionResult')
 return dict(line.split('=',1) for line in output.splitlines())
# This failure-mode exercise requires an isolated container that cannot set time.
status=dict(line.split(':',1) for line in Path('/proc/1/status').read_text().splitlines() if ':' in line)
assert int(status['CapBnd'].strip(),16)&(1<<25)==0,'PID 1 must lack CAP_SYS_TIME'
assert run('systemd-detect-virt','--container')=='docker'
unit='systemd-timesyncd.service';definition=run('systemctl','cat',unit)
assert 'ConditionCapability=CAP_SYS_TIME' in definition
assert 'ConditionVirtualization=!container' in definition
assert properties(unit)['ActiveState']=='inactive'
run('systemctl','start',unit)
state=properties(unit)
assert state=={'MainPID':'0','ActiveState':'inactive','SubState':'dead','ConditionResult':'no'},state
clock=dict(line.split('=',1) for line in run('timedatectl','show','-p','CanNTP','-p','NTP','-p','NTPSynchronized').splitlines())
assert all(value in ('yes','no') for value in clock.values())
print('start command returned zero; unit stayed inactive with PID 0 and failed conditions')
print('clock properties:',json.dumps(clock,sort_keys=True))
print('PID 1 lacks time-setting capability; Docker condition also excludes this packaged service')
print('no clock-setting command was issued and no NTP synchronization was claimed')

启动命令返回零，但单元仍为非活动，主进程编号为零，ConditionResult=no。条件不满足而跳过激活，与守护进程成功运行，是不同结果。样本安装包要求调整时间的能力，并排除容器，而当前环境两项前提都不满足。因此在假设 NTP 报文被网络丢弃之前，就已经有具体证据解释服务为何没有工作。

记录中的时钟属性为 CanNTP=yes、NTP=no、NTPSynchronized=no，分别反映时间服务接口的不同方面。尤其是系统具有 NTP 服务支持，不代表该服务当前活动，也不证明时钟已经同步。脚本输出真实取值，不会把结果替换成预设健康状态；在另一环境中判断时，也应核对当时实际观察，而不是照抄本例的布尔值。

实验没有发出设置时钟的命令，也不声称成功交换 NTP 报文或完成校时。它验证的是一个没有调时权限的容器中的真实激活失败模式。要测试成功校时，需要具备相应权限、可以访问合适时间源的机器，或拥有独立时钟的虚拟机；不能让宿主共享时钟承担一个没有隔离边界的试验，也不能把未运行的客户端写成同步成功。

守护进程真实运行时，可以通过 timedatectl timesync-status 查看客户端自己的服务器与同步信息。但依赖这个接口之前，应先核对服务状态；请求不可用服务时，可能等待 D-Bus 激活并最终超时。本次容器探测达到五秒观察上限，结果被记为没有获得证据，而不是成功同步检查。接口存在、调用返回与内容证明什么，也需要分别判断。

建立能够验证的时间要求

按网络环境选择时间源，并持续观察偏移、延迟与所接受来源的质量。能够连接，并不让服务器自动准确或可信。轮询和根距离设置影响样本处理，但不能仅靠几个配置就把精简客户端变成完整时间分发服务，也不会自动形成某个精度服务承诺。需要什么精度、怎样观察偏差，应由实际应用要求决定。

保存的 /var/lib/systemd/timesync/clock 时间戳，有助于缺少可靠硬件时钟的系统在重启时初始化时间。但它也可能在近期没有成功同步时被周期更新，因此文件存在不证明刚刚接受了网络样本。大致初始化时间与同步到参考时钟，是两个不同里程碑，不应在开机就绪判断中混为一谈。

如果后续工作必须等到时钟同步，应配置并验证相应等待服务，以及排在 time-sync.target 之后的关系。仅启动 timesyncd，不会自动阻止所有应用在准确参考时间到达前运行。应明确启动条件和运行期监控，并以真实部署环境中的证据为准，而不是依赖一个笼统的“NTP 已开启”标签来判断所有时间相关要求已经满足。

来源

systemd 252 systemd-timesyncd.service，SNTP 行为、大偏差跳时、保存的时钟状态与同步信号，已核验 2026-09-12。
systemd 252 timesyncd.conf，时间源选择、后备来源优先级、轮询与根距离限制，已核验 2026-09-12。
systemd 252 org.freedesktop.timedate1，NTP 可用性、启用状态与内核同步属性，已核验 2026-09-12。
systemd 252 systemd-time-wait-sync.service，在确认时间同步后启动依赖服务，已核验 2026-09-12。

服务器时间校准需要可观察的依据

Wed, 02 Sep 2026 00:00:00 +0000

时间守护进程只有在实际状态满足应用要求时才真正有用。进程正在运行，仍可能没有可用来源；已经选择某个来源，也可能尚未充分测量，或者来源本身就不正确。时间服务健康应当是一条可观察的链路：来源配置、成功采样、选择状态、不确定性以及实际允许的时钟控制。进程显示绿色，只能覆盖链路最前面的一部分。

读取守护进程实际报告的内容

Chrony 的 tracking 输出分别给出参考来源、层级、最近更新时间、尚未消除的系统时间修正量、估计频率、频率偏斜不确定性、根延迟和根离散度。它们回答不同问题：offset 关注时间差，frequency 关注时钟走速，skew 反映频率估计的不确定性。根延迟与离散度则参与描述参考路径带来的时间不确定性。只挑一个很小的偏移数值，不能概括整个时钟质量。

sources 输出用于观察候选来源及实际选择。常见显示中的 ^* 表示选中的 NTP 服务器。Reach 是八进制历史位图，377 表示最近八次轮询机会都有成功响应，并不是百分比，也不保证下一次仍然可达。LastRx 有助于查看最近收到的样本已经过去多久。应把来源状态与 tracking 一起读，而不是把进程持续运行时长误认为同步证据。

上游短暂中断后，守护进程可能继续依据已有模型估计时间，但不确定性会随条件变化而扩大。需要根据应用容忍度监控更新时间和误差估计，区分短期维持与无限期可信。多个服务器名称也不必然意味着独立参考，如果它们共享上游或基础设施，仍然可能一起出错。来源选择降低部分故障风险，却不能证明所有上游声明都正确。

今天能够使用的来源，不能证明长时间断联之后启动服务仍然安全。应事先决定业务能否在维持估计期间启动，以及哪项实际测量超过边界就必须阻止启动。还要把这道检查与耗时测量分开：民用时间可能被校正，而超时逻辑需要合适的单调时钟，不能只因同步状态正常就混用两者。

坏掉的样子

容器通常共享宿主的内核时钟，在容器内运行时间服务并不会自然得到一块独立可调的民用时钟。Chronyd 的 -x 模式明确关闭系统时钟控制，但仍保留估计和提供时间服务的能力。因此，客户端可以报告已经同步，系统时钟却并没有被这个进程修正。排查时必须确认实际运行模式，以及哪一层负责宿主时间。

local 指令也容易制造错误信心。它允许 chronyd 在没有外部参考的情况下表现为已同步，可以用于有明确设计的隔离网络安排。但如果只是为了消除告警而启用，就会把缺失参考这一问题隐藏起来。解释 Normal 之前，要核对参考标识以及预期来源政策，不能把某种协议状态直接解释成 UTC 已经准确。

运行检查还需要有意义的限制。Chronyc 的 waitsync 可以等待同步，并可选地限制剩余时间修正量和频率估计偏斜；相应限制为零时，额外约束会被关闭。两个限制都关闭的成功结果，比执行应用专属容忍边界的检查弱得多。即使配置了边界，它也不能替任意上游时钟证明真实性，来源信任仍是另一项要求。

快速验证

使用新的临时 Debian 12 Docker 容器，运行 apt-get update 和 apt-get install -y python3 chrony 安装依赖，将下面代码保存为 chrony-status.py，以 root 执行 python3 chrony-status.py。创建容器时保持独立网络，不使用宿主网络，并移除 SYS_TIME 能力。实测版本为 chrony 4.3 与 Python 3.11.2，代码只在回环地址通信。

from pathlib import Path
from tempfile import TemporaryDirectory
import json
import os
import socket
import subprocess
import time

assert os.geteuid() == 0 and Path('/.dockerenv').exists(), 'use a disposable root Linux container'
with TemporaryDirectory(prefix='chrony-status-') as directory:
 root = Path(directory)
 processes = []
 with socket.socket(socket.AF_INET, socket.SOCK_DGRAM) as reservation:
 reservation.bind(('127.0.0.1', 0))
 port = reservation.getsockname()[1]

 def start(name, extra):
 config = root / (name + '.conf')
 config.write_text(f'pidfile {root}/{name}.pid\ncmdport 0\nbindcmdaddress {root}/{name}.sock\n' + extra)
 process = subprocess.Popen(['chronyd', '-x', '-n', '-u', 'root', '-f', str(config)],
 stdout=subprocess.PIPE, stderr=subprocess.PIPE)
 processes.append(process)
 deadline = time.monotonic() + 5
 while not (root/(name+'.sock')).exists():
 assert process.poll() is None, 'chronyd exited before command socket was ready'
 if time.monotonic() > deadline:
 raise AssertionError('command socket not ready')
 time.sleep(0.05)
 return process

 def command(name, *args):
 return subprocess.run(['chronyc', '-n', '-h', str(root/(name+'.sock')), *args],
 capture_output=True, text=True, timeout=10)

 def tracking(name):
 result = command(name, 'tracking')
 assert result.returncode == 0, result.stderr
 return {line.split(':', 1)[0].strip(): line.split(':', 1)[1].strip()
 for line in result.stdout.splitlines() if ':' in line}

 try:
 client = start('client', f'port 0\nserver 127.0.0.1 port {port} iburst minpoll 0 maxpoll 0\n')
 before = tracking('client')
 before_gate = command('client', 'waitsync', '1', '0', '0', '0.1')
 assert client.poll() is None and before['Leap status'] == 'Not synchronised'
 assert before_gate.returncode != 0
 start('source', f'port {port}\nbindaddress 127.0.0.1\nlocal stratum 8\nallow 127.0.0.1\n')
 assert command('client', 'burst', '4/4').returncode == 0
 deadline = time.monotonic() + 25
 while time.monotonic() < deadline:
 sources = command('client', 'sources').stdout
 after = tracking('client')
 if '^* 127.0.0.1' in sources and after['Leap status'] == 'Normal':
 break
 time.sleep(0.2)
 else:
 raise AssertionError('local source was not selected')
 assert after['Stratum'] == '9'
 after_gate = command('client', 'waitsync', '1', '0', '0', '0.1')
 assert after_gate.returncode == 0
 source_tracking = tracking('source')
 assert source_tracking['Reference ID'].startswith('7F7F0101')
 print(json.dumps({'daemon_alive_while_unsynchronised': True,
 'before': before, 'after': after, 'selected_sources': sources,
 'waitsync_returncodes': [before_gate.returncode, after_gate.returncode],
 'source_reference': source_tracking['Reference ID'],
 'system_clock_adjustment_disabled': True,
 'external_UTC_accuracy_tested': False}))
 finally:
 for process in reversed(processes):
 process.terminate()
 process.communicate(timeout=5)

程序首先启动一个指向尚无人监听端口的客户端。进程仍然存活，但 tracking 显示 Not synchronised，只尝试一次的 waitsync 返回失败。随后启动另一进程，以 local stratum 8 提供本地来源，要求客户端突发采样，并等待实际选中它。客户端最终显示 ^* 127.0.0.1、层级九和 Normal；同一个等待检查此时返回成功。

两个进程全程都禁用时钟调整，结束后都会停止。本次记录的初始选择阶段，频率估计的 skew 仍然很大，即使同步等待检查已经通过。来源参考标识为 7F7F0101，说明它工作在本地参考模式，而不是已经连接外部 UTC 来源。程序保留完整输出，避免只截取绿色状态后把这些限制丢掉。

原先记录报告全部断言执行成功，本轮审阅没有重新运行这项使用套接字的实验。没有测试外部 UTC 精度、长时间收敛、丢失来源后的恢复或真实时钟修正。这个反例用于说明监控必须分开解释进程可用性、同步状态、质量边界和时间权威。真正上线时应针对业务要求验证这些层次，不能把一个简单成功退出码写成全部时间保障都已经成立。

来源

chronyc 4.3 manual，跟踪字段、来源选择及 waitsync 阈值，已核验 2026-09-13。
chronyd 4.3 manual，时钟调整及 -x 模式，已核验 2026-09-13。
chrony.conf 4.3 manual，本地参考模式与来源配置，已核验 2026-09-13。
RFC 5905: Network Time Protocol Version 4，同步状态与不确定性，已核验 2026-09-13。
Linux clock_gettime，民用时间与单调时钟行为，已核验 2026-10-15。

NTP · XB 现场笔记

分别检查 timesyncd 服务状态与时钟证据

坏掉的样子

快速验证

建立能够验证的时间要求

延伸阅读

来源

服务器时间校准需要可观察的依据

读取守护进程实际报告的内容

坏掉的样子

快速验证

延伸阅读

来源