În cutia noastră de producție, mă confrunt cu o problemă cu ntpd. Activez caracteristica NTP pentru caseta noastră de producție și observ o problemă.
Pornim demonul ntpd în procesul de inițializare a casetei noastre. În acest timp conexiunea la internet nu există. Mai jos este micuța mea ntp.conf fişier
driftfile /etc/ntp.drift
logconfig =syncstatus
server pool.ntp.org iburst
Cutia noastră primește conexiunea la internet puțin târziu odată ce interfața apare. Acea dată văd că ntpd nu sincronizează ceasul. Cand fac ntpq -c ca , Eu iau nu a fost găsit nici un ID de asociere. Am așteptat aproape 30 de minute, dar tot am primit nu a fost găsit nici un ID de asociere
Trebuie să repornesc ntpd-ul. După repornirea acestuia, ntpd sincronizează ceasul și totul funcționează normal.
Dar din nou, dacă îmi repornesc cutia, se întâmplă aceeași problemă. Din nou, trebuie să repornesc ntpd, odată ce apare caseta și internetul este accesibil.
S-a confruntat cineva cu o problemă similară?
Ar trebui să amân pornirea ntpd până când apare interfața de timp?
Actualizați
Am mai făcut un experiment și l-am înlocuit server pool.ntp.org iburst cu pool pool.ntp.org iburst iar cu această schimbare ntpd sincroniza automat ceasul. Nu a trebuit să repornesc ntpd-ul. Așa că aici îmi apare o altă întrebare.
Ce s-a întâmplat când am înlocuit Server cu bazin?
Ar trebui să folosesc întotdeauna bazin cuvânt cheie în loc de Server?
Când ar trebui să folosesc bazin si cand ar trebui sa folosesc Server?
Am făcut câteva cercetări și am găsit asta
pool este același cu server, cu excepția faptului că rezolvă un nume în mai multe adrese și le folosește pe toate
dacă fac același lucru, atunci de ce server pool.ntp.org iburst nu a funcționat pentru mine, dar pool pool.ntp.org iburst a lucrat.
Actualizați
După cum am sugerat, am folosit bazin în loc de Server dar totuși ceasul meu nu se poate sincroniza la pornire. Anterior nu a fost găsit nici un ID de asociere venea, dar după ce a folosit pool-ul afișează lista.
GW:/admin# ntpq -c lpeer
telecomandă refid st t când sondaj atinge întârziere offset jitter
==================================================== =============================
time.google.com .POOL. 16 p - 64 0 0.000 +0.000 0.002
GW:/admin# ntpq -np
telecomandă refid st t când sondaj atinge întârziere offset jitter
time.google.com .POOL. 16 p - 64 0 0.000 +0.000 0.002
GW:/admin# ntpq -c ca
ind assid status conf reach auth condition last_event cnt
==================================================== =========
1 34173 8811 da niciunul niciunul respinge mobilizează 1
GW:/admin# ntpq -c „rv 34173”
associd=34173 status=8811 conf, bcast, sel_reject, 1 eveniment, mobilizare,
srcadr=0.0.0.0, srcport=0, srchost="time.google.com", dstadr=0.0.0.0,
dstport=0, leap=11, strat=16, precizie=-19, rootdelay=0,000,
rootdisp=0.000, refid=POOL, reftime=(fără timp), rec=(fără timp), reach=000,
unreach=0, hmode=3, pmode=0, hpoll=6, ppoll=10, headway=0,
flash=1400 peer_dist, peer_unreach, keyid=0, offset=+0,000, întârziere=0,000,
dispersie=16000.000, jitter=0.002,
filtdelay= 0,00 0,00 0,00 0,00 0,00 0,00 0,00 0,00,
filtoffset= +0,00 +0,00 +0,00 +0,00 +0,00 +0,00 +0,00 +0,00,
filtdisp= 16000,0 16000,0 16000,0 16000,0 16000,0 16000,0 16000,0 16000,0
Văd starea blițului ca 1400. Ce înseamnă 1400 Nu am putut găsi starea blițului 1400 în documentația ntp.
Actualizați
A început să funcționeze. am inlocuit iburst cu minpoll 3 maxpoll 4 și după aceea lucrează la repornire. Am folosit piscina asa pool pool.ntp.org minpoll 3 maxpoll 4.
Nu sunt sigur ce diferență face această schimbare.
Am mai citit că ar trebui să evităm să folosim minpoll și maxpoll.
Prea frecvent pentru o perioadă susținută și serviciile publice NTP vă pot bloca. ntpd este deja bun la selectarea dinamică a intervalului de pool.
Oricum, vă mulțumesc tuturor pentru că m-ați ajutat.
