最近有遇到一例比较有趣的Linux下NTP时间同步问题，尝试了使用GDB调试的方法解决，在这里分享一些个人的心得，希望对大家有些帮助。
问题现象：
ECS Linux CentOS实例中时间经常出现偏差，客户已经根据官方文档配置了NTP时间同步，同步源为文档中指定的公网NTP服务器：
https://help.aliyun.com/knowledge_detail/40583.html
尝试调整一些同步频率的参数，并没有实际效果。其中注意到一个现象，如果我们列出NTP日志中信息，会发现一旦出现 "no servers reachable" 之后，ntpd就会停止同步。
而如果重启ntpd同步问题就会暂时得到解决，过了一天左右问题又会复现。
调试过程：
由于通过普通的ntpd的调整一些参数无法解决问题，决定采用GDB现场调试的方式来看看问题发生时为什么ntpd不再同步。
调试之前我们首先要确认ntpd更新系统时间是具体在哪个函数中实现的。因此首先采用阅读Linux NTP代码的方式将范围缩小，确认具体代码段如下：
void
clock_select(void)
{
...
clock_update(); <----------- 更新系统时间
因此我首先将断点设在clock_select，结果是可以中到，得到的堆栈如下：
因此我进一步可以设置断点到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调试的方法来解决一些服务产生的问题，希望给大家提供解决问题的另一种思路。
