最近有遇到一例比较有趣的Linux下NTP时间同步问题，尝试了使用GDB调试的方法解决，在这里分享一些个人的心得，希望对大家有些帮助。

问题现象：

  ECS Linux CentOS实例中时间经常出现偏差，客户已经根据官方文档配置了NTP时间同步，同步源为文档中指定的公网NTP服务器尝试调整一些同步频率的参数，并没有实际效果。其中注意到一个现象，如果我们列出NTP日志中信息，会发现一旦现 "no servers reachable" 之后，ntpd就会停止同步。而如果重启ntpd同步问题就会暂时得到解决，过了一天左右问题又会复现。

调试过程：

  由于通过普通的ntpd的调整一些参数无法解决问题，决定采用GDB现场调试的方式来看看问题发生时为什么ntpd不再同步。

  调试之前我们首先要确认ntpd更新系统时间是具体在哪个函数中实现的。因此首先采用阅读Linux NTP代码的方式将范围缩小，确认具体代码段如下：

void

clock_select(void)

{

...

clock_update(); <----------- 更新系统时间

因此我首先将断点设在clock_select，结果是可以中到，得到的堆栈如下：

因此我进一步可以设置断点到clock_update附近：

设置断点到clock_update但是这次没有中，因此可以判定是在之前的逻辑判断中跳出了。进一步跟踪后发现：

for (n = 0; n < NTP_HASH_SIZE; n++) {

for (peer = peer_hash[n]; peer != NULL;peer =

peer->next) {

peer->flags &= ~FLAG_SYSPEER;

peer->status = CTL_PST_SEL_REJECT;

/*

* Leave the island immediately if the peer is

* unfit to synchronize.

*/

if (peer_unfit(peer))

continue;

  如上代码我们对每一个时间同步源会调用peer_unfit来判断他是否“适合”做时间同步。如果所有同步源都不适合做同步的话，自然就会跳出。因此接下去我们可以考虑设置断点在peer_unfit，并且查看其返回值：

    注意上图是在本地正常的测试机上截取的，而在用户机器上返回值寄存器rax为1，因此可以判断所有配置的同步源被peer_unfit中的逻辑判断为不适合做同步。

因此我们接下去就可以使用相同的方法对peer_unfit做进一步跟踪：

我们发现失败在如下的检查：

if (root_distance(peer) >= sys_maxdist + clock_phi *

ULOGTOD(sys_poll))

rval |= TEST11;     /* distance exceeded */

汇编代码如下：

汇编代码

    这表明计算下来本地时钟和远端NTP服务器的distance过大。clock_phi 是晶振的频率为0.000015，而sys_poll是同步的询问时间，两者相乘是非常小的。所以主要比较的是当前的distance和sys_maxdist，后者默认为1。

root_distance是一个相对复杂的计算：

dist += max(sys_mindisp, dist + peer->delay) / 2 +

peer->rootdispersion + peer->disp + clock_phi *

(current_time - peer->update) + peer->jitter;

其中可以发现他和当前时钟和NTP服务上次成功的时间，两者的差值有关。因此如果时钟走的比较快，而有一次甚至几次同步失败，整个NTP服务就有可能不会再进行同步了。

寻找解决方案：

以上比较的几个参数中唯一可调的就是sys_maxdist，我们可以继续阅读Linux代码来了解怎么调整他：

case CONF_TOS_MAXDIST:

proto_config(PROTO_MAXDIST, 0, ftemp, NULL);

因此我们可以通过在ntp.conf中添加"tos maxdist"可以增大，从而容忍本地时钟过快。

以上一例是采用GDB调试的方法来解决一些服务产生的问题，希望给大家提供解决问题的另一种思路。