ntpdate e ntpd non riescono a sincronizzare l'orologio su Linux

Ho uno strano problema con uno dei miei server. ntpde ntpdatenon funzionano, ma il debug non mostra alcun errore. All'inizio ho pensato che forse un firewall locale o di rete stesse bloccando la porta UDP 123, ma non è questo il caso: questo server può comunicare con la porta UDP 123 (il protocollo ntp) a Internet e ottenere risposte.

Vorrei dimostrare il problema.

date -s "30 DEC 2012 02:30:00" - funziona, quindi posso impostare correttamente l'orologio senza errori.

ntpq -pn pool.ntp.org - funziona, ricevo dati temporali dettagliati dal timeserver e dimostra che i pacchetti UDP funzionano.

ntpdate -d pool.ntp.org - la modalità debug funziona, mostra una tonnellata di dati di debug e mostra la differenza di tempo corrente: 30 Dec 02:38:56 ntpdate[19267]: step time server 208.97.140.69 offset 228.234554 sec

Tutto sembra normale, fino a quando: ntpdate pool.ntp.org- dopo una pausa di 4,7 secondi, restituisce: 30 Dec 02:41:29 ntpdate[19274]: no server suitable for synchronization found

Problema simile in esecuzione ntpd, non aggiorna l'orologio.

Dopo l'avvio di ntpd, ntpq -pntutti i refid rimangono bloccati per sempre, il .INIT.che significa che non possono essere sincronizzati.

/ var / lib / ntp / drift è l'impostazione di driftfile in ntp.conf, che è chmod 644 e di proprietà di ntp: ntp, come tutti gli altri miei sistemi.

Ho provato una dozzina di altri server ntp time, disabilitato il firewall iptables e confermato che il datacenter non sta filtrando il traffico udp. Qualche idea su cosa impedisce a ntpd e ntpdate di sincronizzare il mio orologio?

Questo è CentOS 6.3 x64 su un server dedicato con CPU Intel.

ntpdate(e ntpd) rifiuteranno di (facilmente) impostare l'ora se l'offset è troppo alto. Entrambe le applicazioni proveranno a regolare lentamente il tempo, in modo da non confondere il sistema o eventuali applicazioni che potrebbero non gestire molto bene i salti di tempo.

Prova ntpdate -binvece. Imposta l'ora, per quanto irragionevole possa sembrare.

Potrebbe anche essere necessario aggiungere il -uflag, che impedirà l' ntpdateutilizzo di porte privilegiate (<1024). Si noti che -uè implicito da -d! E sembra che funzioni -dbene.

Se l'aggiunta -ufa la differenza tra funzionante e non funzionante, allora hai un firewall sul modo in cui sta causando questi problemi.

E purtroppo non sembra essere possibile ntpdutilizzare una porta senza restrizioni .

Potete fornire i seguenti output in pastebin.

cat /etc/ntp.conf
cat /etc/sysconfig/ntpd
ntpq -pn
ntpdc -c sysstat
ntpdc -c kerninfo
ntpdc -c loopinfo
ntpdate -d <time-server-IP>
ntptrace

Stai eseguendo la sincronizzazione da server stratum 1 o qualsiasi altra cosa.

Nessun server adatto per la sincronizzazione indica ciò che indica che la comunicazione tra client e server non può essere stabilita.

Se non riusciamo a trovare indizi da questo insieme di dati, potrebbe essere necessario tcpdump per vedere dove si sta perdendo il pacchetto.

tcpdump -s0 -i ethX -p udp -w /tmp/ntp.pcap

Fermati e avvia il demone ntpd e attendi che la portata raggiunga il 377 e quindi ferma il tcpdump. Ciò dovrebbe fornire ulteriori indizi.