Linux下GDB調試NTP時間同步問題

  最近有遇到一例比較有趣的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調試的方法來解決一些服務產生的問題，希望給大家提供解決問題的另一種思路。