Điểm:0

ntpd -g does not sync the clock

lá cờ cn

From ntpd man page

If time is more than 1000s from the server time, ntpd assumes something must be terribly wrong and the only reliable action is for the operator to intervene and set the clock by hand. This causes ntpd to exit with a panic message to the system log. The -g option overrides this check and the clock will be set to the server time regardless of the chip time.

I have done small experiment to test -g option with ntpd. First I changed the system clock time to some old time with date command.

date -s 2021.06.15-19:10:21

After that I created small /etc/ntp.conf file with below information

driftfile  /etc/ntp.drift
logconfig =syncstatus
server time.google.com minpoll 3 maxpoll 4

After that I ran ntpd with below command

ntpd -g -n -4 -c /etc/ntp.conf &

Please note that my ntp.drift file was empty.

I see no change in the system time , infact ntp status shows that clock is not synchronized.

GW:/# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
  ==============================================================================
    time2.google.co .GOOG.           1 u    -   64    1    0.000   +0.000   0.000


Clock is not synchronized, stratum 16, reference is INIT
frequency is +0.000 Hz, precision is -19
reference time is (no time),
clock offset is +0.000000 msec, root delay is 0.000 msec
root dispersion is N/A

Can someone please help me. Did I missed any configuration or some other data.

Apart from this I have one small question

Does ntp clock need to be synchronised for ntp authentication? If ntp clock is not synchronised then in that case will ntp server authentication pass.

Edit:

Below are the logs come when I start ntpd

GW:~/var/log# cat ntpd.log
15 Jun 19:21:03 ntpd[14560]: Listen and drop on 0 v4wildcard 0.0.0.0:123
15 Jun 19:21:03 ntpd[14560]: Listen normally on 1 lo 127.0.0.1:123
15 Jun 19:21:03 ntpd[14560]: Listen normally on 2 srcr2 192.168.0.2:123
15 Jun 19:21:03 ntpd[14560]: Listen normally on 3 log0 1.0.0.1:123
15 Jun 19:21:03 ntpd[14560]: Listening on routing socket on fd #20 for interface updates
15 Jun 19:21:03 ntpd[14560]: kernel reports TIME_ERROR: 0x2041: Clock Unsynchronized
15 Jun 19:21:03 ntpd[14560]: kernel reports TIME_ERROR: 0x2041: Clock Unsynchronized

Update:

@John I have done what ever you suggested but still I see same issue

GW:~/var/log# systemctl status ntpd
ntpd.service - NTPD daemon


Loaded: loaded (/etc/systemd/system/ntpd.service; disabled;   vendor  preset: enabled)
Active: active (running) since Fri 2021-07-09 08:17:46 UTC; 6min ago
Process: 21151 ExecStart=/bin/sh -c /sbin/ntpd -g  >> /var/log  /ntpd.log 2>&1  (code=exited, status=0/SUCCESS)
Main PID: 21153 (ntpd)
CGroup: /system.slice/ntpd.service
       └─21153 /sbin/ntpd -g
       

cat /etc/ntp.conf 
 # use a random selection of 4 public stratum 2 servers
 # see http://twiki.ntp.org/bin/view/Servers/NTPPoolServers
 #restrict default nomodify notrap noquery
 #restrict default noquery

logfile /var/log/ntpd.log
driftfile  /etc/ntp.drift
logconfig =syncstatus

server time1.google.com iburst
server time2.google.com iburst
server time3.google.com iburst
server time4.google.com iburst
#tried pool time.google.com also


GW:~/var/log# ntpq -c as
ind assid status  conf reach auth condition  last_event cnt
===========================================================
1  8426  9014   yes   yes  none    reject   reachable  1
2  8427  9014   yes   yes  none    reject   reachable  1
3  8428  9014   yes   yes  none    reject   reachable  1
4  8429  9014   yes   yes  none    reject   reachable  1

GW:~/var/log# ntpq -c lpeer
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 time1.google.co .GOOG.           1 u    -   64  377    0.000   +0.000   0.000
 time2.google.co .GOOG.           1 u    -   64  377    0.000   +0.000   0.000
 time3.google.co .GOOG.           1 u    -   64  377    0.000   +0.000   0.000
 time4.google.co .GOOG.           1 u    -   64  377    0.000   +0.000   0.000


GW:~/var/log# cat ntpd.log
9 Jul 08:17:46 ntpd[21153]: Listen and drop on 0 v6wildcard [::]:123
9 Jul 08:17:46 ntpd[21153]: Listen and drop on 1 v4wildcard 0.0.0.0:123
9 Jul 08:17:46 ntpd[21153]: Listen normally on 2 lo 127.0.0.1:123
9 Jul 08:17:46 ntpd[21153]: Listen normally on 3 srcr2 192.168.0.2:123
9 Jul 08:17:46 ntpd[21153]: Listen normally on 4 log0 1.0.0.1:123
9 Jul 08:17:46 ntpd[21153]: Listening on routing socket on fd #21 for interface updates
9 Jul 08:17:46 ntpd[21153]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
9 Jul 08:17:46 ntpd[21153]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized

GW:~/var/log#

Can you please check once. Did I missed anything?

Update

Pasting ntpd association output

GW:/# ntpq -c as
ind assid status  conf reach auth condition  last_event cnt
===========================================================
  1 47211  9014   yes   yes  none    reject   reachable  1
  2 47212  9014   yes   yes  none    reject   reachable  1
  3 47213  9014   yes   yes  none    reject   reachable  1
  4 47214  9014   yes   yes  none    reject   reachable  1

GW:/# GW:/#

 GW:/# ntpq -c "rv 47211"
 associd=47211 status=9014 conf, reach, sel_reject, 1 event,   reachable, 
srcadr=time1.google.com, srcport=123, dstadr=192.168.0.2,  dstport=123,
leap=00, stratum=1, precision=-20, rootdelay=0.000,   rootdisp=0.107,
refid=GOOG, reftime=e4a0073d.cba4777a  Mon, Jul 19 2021 14:14:21.795,
rec=e4a0073d.cba4777b  Mon, Jul 19 2021 14:14:21.795, reach=017,
unreach=0, hmode=3, pmode=4, hpoll=6, ppoll=6, headway=347,
flash=400 peer_dist, keyid=0, offset=+0.000, delay=0.000,
dispersion=15937.500, jitter=0.000, xleave=0.033,
filtdelay=  2833222 2833222 2833222 2833222 2833222 2833222 2833222 2833222,
filtoffset= +141661 +141661 +141661 +141661 +141661 +141661 +141661 +141661,
filtdisp=   16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0
lá cờ jp
Dom
Bạn có chắc chắn rằng không có tường lửa giữa ntp của bạn và google không? Nếu thời gian được đặt trong phần cứng được đặt chính xác, ntpd có thể liên hệ với google và duy trì thời gian chính xác không?
vivek avatar
lá cờ cn
@Dom mình làm ntpdate -u time.google.com thì nó cập nhật giờ nên mình nghĩ là không có tường lửa. Có lệnh nhanh nào tôi có thể kiểm tra tường lửa không
Gerard H. Pille avatar
lá cờ in
Tôi muốn xóa dòng logconfig khỏi ntp.conf, có lẽ bạn đang ẩn một số thông báo có thể hữu ích.
vivek avatar
lá cờ cn
@Dom Tôi có một câu hỏi khác, bạn có thể vui lòng chia sẻ suy nghĩ của mình về câu hỏi của tôi không. Đồng hồ ntp có cần được đồng bộ hóa để xác thực ntp không? Nếu đồng hồ ntp không được đồng bộ hóa thì trong trường hợp đó xác thực máy chủ ntp sẽ vượt qua.
Gerard H. Pille avatar
lá cờ in
Chỉ đề cập đến xác thực trong hướng dẫn sử dụng ntpd, liên quan đến việc khách hàng xác thực với máy chủ. time.google.com có ​​yêu cầu xác thực không?
lá cờ jp
Dom
@vivek xin lỗi, tôi không biết về đồng hồ hợp lệ cần thiết để xác thực. Tôi cho rằng nó không cần thiết, nhưng tôi không bao giờ sử dụng auth. Bạn có thể thêm một máy chủ mới như "pool.ntp.org" để xem nó có thay đổi gì không
John Mahowald avatar
lá cờ cn
Vui lòng thêm các biến từ một liên kết: `ntpq -c "rv 8426"` từ đó chúng tôi có thể diễn giải trạng thái flash https://www.eecis.udel.edu/~mills/ntp/html/decode.html
vivek avatar
lá cờ cn
@JohnMahowald Tôi đã thêm các biến từ một hiệp hội
Điểm:3
lá cờ cn

Thông thường sau khi cho phép NTP thông qua bất kỳ tường lửa nào, một số gói đầu tiên được xử lý (tăng phạm vi tiếp cận), hệ thống ngang hàng được chọn và bước đầu tiên sẽ sửa thời gian. Hệ thống này có các đồng nghiệp có thể truy cập được nhưng lại từ chối tất cả, điều này thật kỳ lạ.

Sau khi xem xét đầu ra readvar, rootdelay=0.000 không có ý nghĩa. Điều khiển từ xa qua internet, không thể bằng không. Có thể tại sao bạn lại nhận được một từ flash vượt quá ngưỡng khoảng cách.

Một lý thuyết từ IRC là các gói NTP đang bị xáo trộn bởi một số hộp trung gian. Điều đó nếu đúng sẽ rất tệ vì nó rõ ràng đã phá vỡ NTP. ntpd áp dụng dscp vào các gói của nó nhưng ntpdate thì không. Cố gắng dscp 0 trong ntp.conf Hỏi xung quanh xem các hộp nhận biết dịch vụ khác biệt có nằm trong đường dẫn không. Chụp gói (tcpdump) của các gói NTP và xem nó trong Wireshark. Xem liệu nó có thể phân tích cả hai trường DSCP bất kỳ hay không, gói các gói NTP bằng dấu thời gian NTP.

Ngoài ra, hãy nghiên cứu ntpd trong một mạng hoàn toàn khác để so sánh nó trông như thế nào khi hoạt động. ntpd có thể chạy trên mọi thứ, vì vậy có thể là VM trên máy trạm của bạn.

Câu trả lời ban đầu của tôi với một bài phê bình về cấu hình sau đây.


Reach của bạn được ghi lại chỉ có 1. Đợi 3 phút sau khi bắt đầu ntpd. Mất một thời gian để nhận được một vài gói đầu tiên được trả lại.

Về cấu hình của bạn:

thời gian máy chủ.google.com minpoll 3 maxpoll 4

xem xét thêm tôi bật đến máy chủ của bạn và dòng hồ bơi. Bùng nổ ban đầu khi khởi động một số gói với độ trễ ngắn.

Tôi không tin cấu hình hồ bơi nhỏmaxpool là một ý tưởng tốt, Mũ đỏ cũng vậy. Quá thường xuyên trong một thời gian dài và các dịch vụ NTP công cộng có thể chặn bạn. ntpd đã rất giỏi trong việc tự động chọn khoảng thời gian nhóm.

Cần nhiều máy chủ NTP hơn, lý tưởng nhất là 4 máy chủ để phát hiện những kẻ giả mạo với dự phòng n+1. NTP công khai của Google có 4 giao diện người dùng, mà bạn có thể sử dụng với một trong hai hồ bơi chỉ thị hoặc nhiều dòng máy chủ. Vui lòng thêm các dịch vụ NTP khác làm ý kiến ​​thứ hai, như 2.pool.ntp.org. (Tuy nhiên bạn sẽ có một mớ hỗn độn bước nhảy vọt thứ hai nếu máy chủ NTP của bạn không đồng ý về điều đó.)

Không, các dịch vụ NTP công cộng không yêu cầu xác thực NTP. Xác thực không phải là vấn đề của bạn, cho phép các bước lớn và điều chỉnh tỷ lệ thăm dò ý kiến.

Thay đổi được đề xuất của tôi cho dòng máy chủ giống như thế này:

pool time.google.com iburst

Về cách bạn bắt đầu ntpd:

ntpd -g -n -4 -c /etc/ntp.conf &

-g tùy chọn là cần thiết để sửa một khoảng bù lớn như vậy trong nhiều giờ, hãy giữ nó. Cho phép bước vô hạn một lần khi bắt đầu. Thông thường, phần bù lớn khiến ntpd hoảng sợ. Sử dụng -g trong bất kỳ tập lệnh nào khởi động ntpd, vì vậy thời gian sẽ được cố định khi khởi động.

Tôi không thấy mục đích của việc không có fork cộng với nền shell. Để bắt đầu ở chế độ nền, tôi sử dụng trình quản lý dịch vụ của hệ thống hoặc tập lệnh init. Ví dụ, một đơn vị ntpd.service dành cho Linux với systemd.

Xóa bỏ -4. Google có khả năng IPv6.

Nếu bạn muốn đặt thời gian một lần và thoát, -q tùy chọn là hữu ích. Để sử dụng tương tác khi khắc phục sự cố, hoạt động bình thường là để ntpd chạy. Không sử dụng ntpdate, lỗi thời.

ntpd -g -q
vivek avatar
lá cờ cn
Tôi đồng ý rằng máy chủ công cộng không cần xác thực. Ý tôi là, nếu giả sử đồng hồ của tôi chậm hơn 1 ngày so với thời gian thực tế và ntpd cũng không đồng bộ hóa đồng hồ nếu khoảng cách thời gian quá cao (nếu chúng tôi không sử dụng -g và ntpdate) thì trong trường hợp đó, tôi sẽ xác thực được thông qua hoặc nó sẽ thất bại do khoảng cách thời gian lớn. Ý tôi là xác thực có vượt qua nếu khoảng cách thời gian lớn không?
John Mahowald avatar
lá cờ cn
-g tùy chọn là những gì cho phép một bước nhảy lớn như vậy và chỉ khi bắt đầu ntpd. Bạn có tùy chọn này nên câu trả lời đầu tiên của tôi không thảo luận về nó, xem phần chỉnh sửa.
John Mahowald avatar
lá cờ cn
Chỉnh sửa để thêm lý thuyết gói đọc sai. Một chút phi thường, nhưng tôi đã đề cập đến tất cả những điều bình thường mà tôi có thể nghĩ ra.

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.