Nguyên nhân có thể khiến NTPD chết đột ngột và giải pháp

Trên một ứng dụng web sử dụng s3 để lưu trữ tài liệu vật lý, chúng tôi đang gặp vấn đề với NTP liên tục chết. Điều này dường như xảy ra khoảng một hoặc hai lần một ngày. Có rất ít thông tin được cung cấp khi điều này xảy ra, ngoài tệp PID tồn tại nhưng dịch vụ đã chết khi tôi kiểm tra trạng thái.

Bất cứ ai có thể đề nghị nguyên nhân có thể của NTPD chết? Tôi giả định rằng có lẽ sự trôi dạt của đồng hồ đang khiến nó chết nhưng tôi cũng không chắc điều gì sẽ gây ra điều đó. Có quá nhiều bộ nhớ và dung lượng đĩa trống.

Lần cuối cùng dịch vụ chết, đây là đầu ra:

Sep  6 06:15:25 vm02 rsyslogd: [origin software="rsyslogd" swVersion="5.8.10" x-pid="988" x-info="http://www.rsyslog.com"] rsyslogd was HUPed
Sep  6 06:17:06 vm02 ntpd[10803]: 0.0.0.0 0618 08 no_sys_peer
Sep  6 08:01:10 vm02 ntpd[10803]: 0.0.0.0 0617 07 panic_stop -28101 s; set clock manually within 1000 s.

Tôi muốn nói rằng không có phương pháp 1 phút nào để tìm ra lý do chính xác.

Chúng tôi đã có vấn đề tương tự trước đây trong môi trường ESXi của chúng tôi. Để cắt ngắn câu chuyện, chúng tôi thấy đồng hồ của máy chủ ESXi bị trôi rất nhiều và máy ảo khách đang đồng bộ hóa thời gian từ cả máy chủ ESXi và máy chủ NTP ngược dòng. Điều này khiến NTPd trên máy ảo bị nhầm lẫn do đó chết khá thường xuyên.

Trong một số trường hợp hiếm hoi, chúng tôi cũng phát hiện mất gói ngẫu nhiên cũng khiến NTPd thoát vì thời gian khứ hồi giữa máy chủ của bạn và máy chủ NTPd ngược dòng được sử dụng để tính thời gian trôi.

Trong hai trường hợp trên, nếu NTPd thấy thời gian trôi rất lớn, ví dụ hơn 1000 giây, nó sẽ thoát theo mặc định. Tùy chọn -g sẽ giúp một chút.

   -g      Normally,  ntpd  exits  with  a  message to the system log if the offset exceeds the panic threshold,
           which is 1000 s by default. This option allows the time to be set to any value  without  restriction;
           however,  this  can  happen only once. If the threshold is exceeded after that, ntpd will exit with a
           message to the system log. This option can be used with the -q and -x options. See the tinker command
           for other options.

Bạn có thể xem nhật ký hệ thống , trong đó có một số từ có thể cung cấp cho bạn một gợi ý. Bạn cũng có thể theo dõi đầu ra "ntpq -p" để có ý tưởng sơ bộ về cách thức bù đắp phát triển.

Thông điệp tường trình chỉ rõ rằng sự trôi dạt của đồng hồ là lý do cho việc thoát. Phương pháp khả thi:

• Bắt đầu ntpd với cờ -g; tuy nhiên, điều này sẽ không khắc phục được nguyên nhân gốc rễ, đó là lệch đồng hồ.
• Chạy ntpdate trước khi bắt đầu ntpd; có lẽ cùng cảnh báo.

• Thêm nhiều nguồn thời gian hơn; NTP cần 4 - 6 nguồn để duy trì độ chính xác tốt. Một cách đơn giản để làm điều này là bao gồm các tham chiếu lặp đi lặp lại đến [0-3] .YOURREGION.pool.ntp.org trong cấu hình của bạn, ví dụ:

  server 0.au.pool.ntp.org iburst
  server 1.au.pool.ntp.org iburst
  server 2.au.pool.ntp.org iburst
  server 3.au.pool.ntp.org iburst
  
  server 0.au.pool.ntp.org iburst
  server 1.au.pool.ntp.org iburst
  server 2.au.pool.ntp.org iburst
  server 3.au.pool.ntp.org iburst
  

Một lựa chọn khác bạn có thể thử là chrony. Trong thử nghiệm của chúng tôi, nó hoạt động ổn định hơn ntpd và xử lý thời gian lệch có kinh nghiệm trong môi trường ảo tốt hơn.

http: // syncy.tuxf Family.org/