NTPD'nin beklenmedik bir şekilde ölmesinin nedenleri ve çözümleri

9

Fiziksel belge depolama için s3 kullanan bir web uygulamasında, NTP ile sürekli olarak ölüyoruz. Bu, kabaca günde bir veya iki kez gerçekleşiyor gibi görünüyor. Bu gerçekleştiğinde sağlanan çok az bilgi var, bunun dışında PID dosyası var ama durumu kontrol ettiğimde hizmet öldü.

Herkes NTPD'nin ölmesinin olası nedenlerini önerebilir mi? Belki saat kaymasının ölüme neden olduğunu varsayıyorum ama buna da ne sebep olacağından emin değilim. Yeterli bellek ve kullanılabilir disk alanı var.

Hizmet en son öldüğünde, çıktı:

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.

— user275940
kaynak

Hangi işletim sistemi ve sürüm? Çalışan bir saklanma var mı? Kaç ntp sunucusu yapılandırıldı? Hangi ntpd seçenekleri etkin?

— Nils

Sen ntp.drift dosyanızı kaldırmayı deneyebilirsin, değeri çok yüksek olabilir ve skew neden olabilir

— Rqomey

6

Kesin sebebi bulmak için 1 dakikalık bir yöntem olmadığını söyleyebilirim.

Daha önce ESXi ortamımızda benzer sorunlar yaşadık. Hikayeyi kısaltmak için ESXi ana bilgisayarının saatinin çok sürüklendiğini ve konuk VM'lerin hem ESXi ana bilgisayarından hem de yukarı akış NTP sunucusundan zamanı senkronize ettiğini gördük. Bu, karışık VM'lerde NTPd'nin neden olduğu için oldukça sık öldü.

Ayrıca bazı nadir durumlarda rasgele paket kaybının da NTPd'den çıkmasına neden olduğunu tespit ettik, çünkü sunucunuz ile yukarı akış NTPd sunucusu arasındaki gidiş-dönüş süresi sapma süresini hesaplamak için kullanıldı.

Yukarıdaki iki durumda, NTPd büyük bir zaman kayması görürse, örneğin 1000'den fazla, varsayılan olarak kapanır. -g seçeneği biraz yardımcı olacaktır.

   -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.

Sen olabilir sistem günlüğüne de bakabilirsiniz size bir ipucu verebilir bazı kelimeler olmalıdır. Ofsetin nasıl geliştiği hakkında kabaca bir fikir sahibi olmak için "ntpq -p" çıktısını da izleyebilirsiniz .

— Enzo Wang
kaynak

VM'lerde ntpd çalıştırdığınızda, ana makineyle saati de senkronize etmemelisiniz ve yerel saati referans olarak eklememelisiniz.

— Paul Gear

3

Günlük mesajı, saat sapmasının çıkmanın nedeni olduğunu açıkça belirtir. Olası çözümler:

Ntpd'yi -g bayrağıyla başlatın; ancak bu, saat eğriliği olan temel nedeni düzeltmez.
Ntpd'yi başlatmadan önce ntpdate komutunu çalıştırın; muhtemelen aynı uyarı.

Daha fazla zaman kaynağı ekleyin; NTP'nin doğruluğunu korumak için 4-6 kaynağa ihtiyacı vardır. Bunu yapmanın basit bir yolu, yapılandırmanıza [0-3] .YOURREGION.pool.ntp.org için tekrarlanan referanslar eklemektir.

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

— Paul Gear
kaynak

1

Deneyebileceğiniz başka bir seçenek chrony. Testlerimizde ntpd'den daha kararlı performans gösterir ve sanal ortamlarda yaşanan zaman eğriliğini daha iyi işler.

http://chrony.tuxfamily.org/

— Jokajak
kaynak