☰

将 NTP 服务设置为非活动状态

tag-icon • tag-icon systemd ntp systemd-timesyncd
将 NTP 服务设置为非活动状态

我已经配置 systemd timesyncd 以从 NTP 服务器获取时间：

/etc/systemd/timesyncd.conf > NTP=ca.pool.ntp.org
systemctl restart systemd-timesyncd.service 
timedatectl set-ntp true

状态如下：

$ timedatectl status
...
Network time on: yes
NTP synchronized: no

正如输出所示，时间尚未同步。有人能帮我解决以下问题吗？

  • timesyncd 与 NTP 同步需要多长时间？它以什么间隔执行此操作，我可以在哪里检查和更改它们？
  • 紧急情况下：我只能手动设置时间，还是可以强制 timesyncd 立即与 NTP 服务器同步？

答案1

要使用实际的 NTP 实现，您需要安装并配置一个，chrony或者可能需要ntpd。如果您需要监控时间性能，请这样做。我假设是 chrony。

iburst在配置中添加pool或server 行以加快最初几个数据包的速度。可能仍需要几分钟才能稳定下来，请耐心等待。

编辑 chrony.conf 时，检查允许哪些步骤。例如，makestep 1.0 3表示在 chronyd 启动后的前 3 次更新中，大于 1 秒的偏移会立即设置时钟。对于某些应用程序来说，回到过去是件坏事，因此一旦系统运行，通常不允许大步骤。

在命令行上，可以查询每个变量。

chronyc tracking将显示当前偏移量。了解您的要求是什么，一秒的精度可以轻松容忍几十毫秒的偏移量。

chronyc makestep 不带任何参数将立即进行当前调整。通常不需要，有一个相应的配置文件指令，chrony 会自行稳定地调整时钟。CLImakestep上的用于在您不想重新启动 chronyd 时以交互方式修复 NTP。

timesyncd是一个 SNTP 客户端，可以设置时间，但不能逐步、连续地校准时间，也不能根据质量过滤远程 NTP 服务器。（它也不能与时间硬件或 PTP 通信，只能与 NTP 协议通信。）比重复的要好一点ntpdate，我的意思是时钟不是很好。就我个人而言，我在大多数服务器上都替换了它。

使用 timesyncd 设置时间的唯一方法是手动：timedatectl set-time "2019-01-15 00:40:16"。它没有强大的方法来规范和监控时钟。通过基本 NTP 统计信息timedatectl timesync-status是一个相对较新的东西，我认为 Red Hat 7 或 Ubuntu 18.04 中没有该选项。

systemd 将“syncronized”定义为是否曾使用 NTP 来告诉 Linux 调整时钟。具体来说，如果内核规则调用 adjtimex() 没有错误地返回，而不是初始状态。请参阅源代码 systemd/src/basic/time-util.c。

答案2

无需安装任何其他软件包...关闭 NTP，手动将时间设置为足够接近，重新打开 NTP：

将 NTP 服务设置为非活动状态

$ timedatectl set-ntp false

手动设置时间

获取近似值当地的挂钟、手机和互联网上的时间。它不需要完美，因为我们稍后会重新打开 ntp...

$ sudo timedatectl set-time "2019-06-22 13:41:00"

设置 NTP 服务处于活动状态

$ sudo timedatectl set-ntp true

等待。

等待几分钟。如果响应timedatectl如果没有改变则表示您存在网络问题。

$ timedatectl
               Local time: Sat 2019-06-22 13:49:53 AEST
           Universal time: Sat 2019-06-22 03:49:53 UTC
                 RTC time: Sat 2019-06-22 03:49:54
                Time zone: Australia/Sydney (AEST, +1000)
System clock synchronized: no
              NTP service: active
          RTC in local TZ: no

当系统时钟调整到足以被视为“同步”时，“系统时钟同步：否”将变为“是”。例如：

$ timedatectl 
               Local time: Wed 2020-07-22 09:50:32 AEST  
           Universal time: Tue 2020-07-21 23:50:32 UTC   
                 RTC time: Tue 2020-07-21 23:50:32       
                Time zone: Australia/Sydney (AEST, +1000)
System clock synchronized: yes                           
              NTP service: active                        
          RTC in local TZ: no

和

$ timedatectl timesync-status
       Server: 91.189.91.157 (ntp.ubuntu.com)  
Poll interval: 1min 4s (min: 32s; max 34min 8s)
         Leap: normal                          
      Version: 4                               
      Stratum: 2                               
    Reference: 8CCBCC4D                        
    Precision: 1us (-24)                       
Root distance: 64.781ms (max: 5s)              
       Offset: -88.040ms                       
        Delay: 754.084ms                       
       Jitter: 78.200ms                        
  Packet count: 8                               
     Frequency: -187.812ppm

故障排除

你问谁时间？

$ cat /etc/systemd/timesyncd.conf
[Time]
NTP=pool.ntp.org

我认为这个公共池是最好的，但有些发行版可能有自己的池，或者有区域池，或者你可能只是有一些过时的池；没关系，只要确保它存在并且提供 ntp 服务即可。如果有一个你可以访问的近端服务器，比如防火墙内的公司时间服务器，你可以在这里设置它，或者设置一个后备服务器。请参阅文档了解更多信息。

同步进展如何？

$ timedatectl timesync-status
       Server: 13.210.208.89 (au.pool.ntp.org)
Poll interval: 8min 32s (min: 32s; max 34min 8s)
 Packet count: 0

这次同步进展不顺利：它以 30 秒开始，但轮询间隔已超过 8 分钟。这packet count是传入计数；即：没有响应。请参阅上文中一个健康的示例。轮询间隔会根据时钟漂移的严重程度自动调整。

有任何错误信息吗？

检查系统日志以查找问题可能出在哪里的线索。

$ journalctl --unit=systemd-timesyncd.service
Jun 22 14:13:09 meebox systemd-timesyncd[8333]: Timed out waiting for reply from 103.214.220.220:123 (au.pool.ntp.org).

在这个例子中，传出的数据包没有得到任何回复，因为 ntp 数据包被公司防火墙阻止。

答案3

对我来说另一个故障排除方法是查看

journalctl --unit=systemd-timesyncd.service

6月9日 10:14:14 srvSRVsrv systemd-timesyncd[xxxxx]:服务器根距离过大。正在断开连接。

所以我编辑了vi /etc/systemd/timesyncd.conf

取消注释并设置：

RootDistanceMaxSec=30

重新启动服务 timedatectl 后，这解决了我的问题

答案4

对于那些正在努力解决这个问题的人来说，需要注意的是，如果主机没有授予适当的权限，有时同步在容器化系统（例如 OpenVZ）上根本无法工作。

该systemd-timesyncd服务不会在容器化系统上启动；服务文件包含以下指令：

ConditionVirtualization=!container

尝试注释掉该错误并重新启动服务可能会有效，但除非主机已将权限授予容器化服务，否则输出中可​​能会出现这样的错误systemctl status systemd-timesyncd：

Aug 11 16:01:40 your-machine systemd-timesyncd[4736]: Failed to call clock_adjtime(): Operation not permitted

相关内容