ntpd -g nu sincronizează ceasul

Din ntpd pagina de manual

Dacă timpul este mai mult de 1000 de secunde față de ora serverului, ntpd presupune că ceva trebuie să fie teribil de greșit și singura acțiune de încredere este ca operatorul să intervină și să seteze ceasul manual. Acest lucru face ca ntpd să iasă cu un mesaj de panică în jurnalul de sistem. Opțiunea -g înlocuiește această verificare și ceasul va fi setat la ora serverului, indiferent de ora cipului.

Am făcut un mic experiment pentru a testa -g opțiune cu ntpd. Mai întâi am schimbat ora ceasului sistemului la o oră veche cu comanda dată.

data -s 2021.06.15-19:10:21

După aceea am creat mic /etc/ntp.conf fișier cu informațiile de mai jos

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

După aceea am fugit ntpd cu comanda de mai jos

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

Vă rugăm să rețineți că al meu ntp.deriva fișierul era gol.

Nu văd nicio schimbare în ora sistemului, de fapt starea ntp arată că ceasul nu este sincronizat.

GW:/# ntpq -p
     telecomandă refid st t când sondaj atinge întârziere offset jitter
  ==================================================== =============================
    time2.google.co .GOOG. 1 u - 64 1 0.000 +0.000 0.000


Ceasul nu este sincronizat, stratul 16, referința este INIT
frecvența este +0.000 Hz, precizia este -19
ora de referință este (fără timp),
offset-ul ceasului este de +0,000000 msec, întârzierea rădăcină este de 0,000 msec
dispersia radiculară este N/A

Ma poate ajuta cineva va rog. Am omis vreo configurație sau alte date.

În afară de asta, am o mică întrebare

Ceasul ntp trebuie sincronizat pentru autentificarea ntp? Dacă ceasul ntp nu este sincronizat, atunci în acest caz va trece autentificarea serverului ntp.

Editați | ×:

Mai jos sunt jurnalele care vin când pornesc ntpd

GW:~/var/log# cat ntpd.log
15 iunie 19:21:03 ntpd[14560]: Ascultați și introduceți 0 v4wildcard 0.0.0.0:123
15 iunie 19:21:03 ntpd[14560]: Ascultați normal pe 1 lo 127.0.0.1:123
15 iunie 19:21:03 ntpd[14560]: Ascultați normal pe 2 srcr2 192.168.0.2:123
15 iunie 19:21:03 ntpd[14560]: Ascultați normal pe 3 log0 1.0.0.1:123
15 iunie 19:21:03 ntpd[14560]: ascultare pe soclul de rutare pe fd #20 pentru actualizări de interfață
15 iunie 19:21:03 ntpd[14560]: kernel-ul raportează TIME_ERROR: 0x2041: Ceas nesincronizat
15 iunie 19:21:03 ntpd[14560]: kernel-ul raportează TIME_ERROR: 0x2041: Ceas nesincronizat

Actualizați:

@John Am făcut tot ce mi-ai sugerat, dar încă văd aceeași problemă

GW:~/var/log# starea systemctl ntpd
ntpd.service - demon NTPD


Încărcat: încărcat (/etc/systemd/system/ntpd.service; dezactivat; prestabilit furnizor: activat)
Activ: activ (în rulare) din vineri 2021-07-09 08:17:46 UTC; acum 6 minute
Proces: 21151 ExecStart=/bin/sh -c /sbin/ntpd -g >> /var/log /ntpd.log 2>&1 (code=exited, status=0/SUCCESS)
PID principal: 21153 (ntpd)
CGroup: /system.slice/ntpd.service
       ââ21153 /sbin/ntpd -g
       

cat /etc/ntp.conf 
 # utilizați o selecție aleatorie de 4 servere publice din stratul 2
 # vezi http://twiki.ntp.org/bin/view/Servers/NTPPoolServers
 #restrict default nomodify notrap noquery
 #restrict implicit noquery

fișier jurnal /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, de asemenea


GW:~/var/log# ntpq -c as
ind assid status conf reach auth condition last_event cnt
==================================================== =========
1 8426 9014 da da niciunul respinge accesibil 1
2 8427 9014 da da niciunul respinge accesibil 1
3 8428 9014 da da niciunul respinge accesibil 1
4 8429 9014 da da niciunul respinge accesibil 1

GW:~/var/log# ntpq -c lpeer
     telecomandă refid st t când sondaj atinge întârziere 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 iulie 08:17:46 ntpd[21153]: Ascultați și introduceți 0 v6wildcard [::]:123
9 iulie 08:17:46 ntpd[21153]: Ascultați și introduceți 1 v4wildcard 0.0.0.0:123
9 iulie 08:17:46 ntpd[21153]: Ascultați normal pe 2 la 127.0.0.1:123
9 iulie 08:17:46 ntpd[21153]: Ascultați normal pe 3 srcr2 192.168.0.2:123
9 iulie 08:17:46 ntpd[21153]: Ascultați normal pe 4 log0 1.0.0.1:123
9 iulie 08:17:46 ntpd[21153]: Ascultare pe soclul de rutare pe fd #21 pentru actualizări de interfață
9 iulie 08:17:46 ntpd[21153]: rapoartele nucleului TIME_ERROR: 0x41: Ceas nesincronizat
9 iulie 08:17:46 ntpd[21153]: rapoartele nucleului TIME_ERROR: 0x41: Ceas nesincronizat

GW:~/var/log#

Poți te rog să verifici o dată. Mi-a scăpat ceva?

Actualizați

Lipirea ieșirii asocierii ntpd

GW:/# ntpq -c ca
ind assid status conf reach auth condition last_event cnt
==================================================== =========
  1 47211 9014 da da niciunul respinge accesibil 1
  2 47212 9014 da da niciunul respinge accesibil 1
  3 47213 9014 da da niciunul respinge accesibil 1
  4 47214 9014 da da niciunul respinge accesibil 1

GW:/# GW:/#

 GW:/# ntpq -c „rv 47211”
 associd=47211 status=9014 conf, reach, sel_reject, 1 eveniment, accesibil, 
srcadr=time1.google.com, srcport=123, dstadr=192.168.0.2, dstport=123,
salt=00, strat=1, precizie=-20, rootdelay=0,000, rootdisp=0,107,
refid=GOOG, reftime=e4a0073d.cba4777a Luni, 19 iulie 2021 14:14:21.795,
rec=e4a0073d.cba4777b Luni, 19 iulie 2021 14:14:21.795, reach=017,
unreach=0, hmode=3, pmode=4, hpoll=6, ppoll=6, avans=347,
flash=400 peer_dist, keyid=0, offset=+0,000, întârziere=0,000,
dispersie=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

În mod normal, după ce permiteți NTP prin orice firewall, primele câteva pachete sunt procesate (creșterea acoperirii), este selectat un peer de sistem și pasul inițial fixează timpul. Acest sistem are colegi accesibili, dar i-a respins pe toți, ceea ce este ciudat.

După examinarea rezultatelor readvar, rootdelay=0.000 nu are sens. Telecomanda prin internet, nu poate fi zero. Posibil motivul pentru care ai depășit pragul de distanță.

O teorie de la IRC este că pachetele NTP sunt stricate de o cutie de mijloc. Ceea ce, dacă este adevărat, ar fi rău, deoarece aparent a rupt NTP. ntpd aplică dscp la pachetele sale, dar ntpdate nu. Încerca dscp 0 în ntp.conf Întreabă în jur dacă casete de servicii diferențiate sunt în cale. Luați o captură de pachete (tcpdump) de pachete NTP și priviți-o în Wireshark. Vedeți dacă poate diseca ambele câmpuri DSCP, împachetând pachetele NTP cu marcaje de timp NTP.

De asemenea, studiați ntpd într-o rețea complet diferită pentru a contrasta cum arată când lucrați. ntpd poate rula pe orice, deci poate un VM pe stația ta de lucru.

Urmează răspunsul meu inițial cu o critică a configurației.

Acoperirea dvs. înregistrată acolo este doar 1. Așteptați 3 minute după pornirea ntpd. Este nevoie de ceva timp pentru a primi primele pachete returnate.

În ceea ce privește configurația dvs.:

server time.google.com minpoll 3 maxpoll 4

Luați în considerare adăugarea iburst la serverul dvs. și liniile de piscină. Explozie inițială la pornirea mai multor pachete cu o scurtă întârziere.

Nu sunt convins de configurare minpool și maxpool este o idee buna, nici Red Hat. 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.

Aveți nevoie de mai multe servere NTP, în mod ideal 4 pentru detectarea falseticker-urilor cu redundanță n+1. NTP public Google are 4 interfețe, pe care le puteți folosi fie cu bazin directive sau mai multe linii de server. Simțiți-vă liber să adăugați alte servicii NTP ca a doua opinie, cum ar fi 2.pool.ntp.org. (Totuși, vei avea un dezordine al doilea frotiu dacă serverele dumneavoastră NTP nu sunt de acord cu asta.)

Nu, serviciile publice NTP nu necesită autentificare NTP. Autentificarea nu este problema ta, permițând pași mari și ajustarea ratei de sondaj.

Modificarea mea sugerată pentru linia de server este mai degrabă ca aceasta:

pool time.google.com iburst

Cât despre cum porniți ntpd:

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

-g opțiunea este necesară pentru a repara un astfel de offset mare de multe ore, păstrați-l. Permite pas infinit o dată la pornire. În mod normal, offset mare face ca ntpd să intre în panică. Utilizare -g în orice script care pornește ntpd, deci timpul va fi fixat la pornire.

Nu văd rostul unui fundal fără furcă plus shell. Pentru a începe în fundal, folosesc managerul de servicii al sistemului sau scriptul init. De exemplu, o unitate ntpd.service pentru Linux cu systemd.

Șterge -4. Google este capabil IPv6.

Dacă doriți să setați ora o dată și să ieșiți, -q opțiunea este utilă. Pentru utilizare interactivă la depanare, funcționarea normală lasă ntpd în funcțiune. Nu utilizați ntpdate, care este învechit.

ntpd -g -q