NTP è in esecuzione, l'orologio di sistema non è ancora in tempo - cosa offre?

Un server Debian Stable (5.0.3) è in esecuzione ntpde connesso a Internet. Tuttavia, l'orologio di sistema ha circa 5 minuti di errore.

$ /etc/init.d/ntp status
NTP server is running..

Parti rilevanti (penso) di /etc/ntp.conf:

driftfile /var/lib/ntp/ntp.drift

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

server 0.europe.pool.ntp.org
server 1.europe.pool.ntp.org
server 2.europe.pool.ntp.org
server 3.europe.pool.ntp.org

So che NTP non porta necessariamente l'orologio in tempo immediatamente. Tuttavia, quante ore o giorni devi aspettare per aspettarti ragionevolmente che NTP abbia fatto il suo lavoro e sincronizzato l'orologio?

Mi sto perdendo qualche altro file o opzione di configurazione o sto semplicemente facendo qualcosa di sbagliato? È ntp (invece che ad esempio ntpdate ) lo strumento giusto per questo? Esiste un modo rapido per verificare se la configurazione è corretta e se i server NTP scelti restituiscono l'ora corretta?

Modifica : l'output di ntpq -pè:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 ns1.nexellent.n .INIT.          16 u    - 1024    0    0.000    0.000   0.000
 dnscache-madrid .INIT.          16 u    - 1024    0    0.000    0.000   0.000
 sinister.wzw.tu .INIT.          16 u    - 1024    0    0.000    0.000   0.000
 dnscache-frankf .INIT.          16 u    - 1024    0    0.000    0.000   0.000

Modifica 2 : viene restituito il ntpdate -u 0.europe.pool.ntp.orgcomando ( suggerito da Brent )

17 Dec 17:37:29 ntpdate[14195]: no server suitable for synchronization found

... anche se su altre macchine quel comando funziona benissimo. Quindi esamineremo le impostazioni di rete / firewall per questo particolare server (che si trova in una rete diversa, accessibile tramite VPN).

Soluzione : il colpevole non era il firewall locale sul nostro server, ma le impostazioni del firewall da qualche parte nella rete circostante. Quindi abbiamo chiesto al provider di hosting del server di consentire NTP per i nostri computer e ora funziona bene. Ad esempio, ntpq -pora restituisce:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 ns1.eunet.fi    192.36.144.23    2 u   10   64    1    1.043    0.258   0.001
 ns2.eunet.fi    62.142.10.44     2 u    9   64    1    0.671    0.135   0.001
 ns3.eunet.fi    62.142.10.44     2 u    8   64    1    0.750    0.277   0.001

(Siamo anche passati ai server eunet.fi consigliati dalla società di hosting, ma non è questo il punto.) I comandi nella risposta di Brent sono stati utili perché mi hanno fatto capire che il problema era l'accesso alla rete ai server NTP, non nella configurazione NTP si. Grazie a tutti!

Arresta ntpd, esegui ntpdate -u 0.europe.pool.ntp.org3 volte, avvia ntpd, verifica ntpq -p, ritardo, offset e jitter devono essere diversi da zero.

Se dovessi indovinare il perché e supponendo che tu abbia la connettività di rete e riesca a vedere il tuo host NTP senza problemi, è possibile che tu sia passato a un valore elevato. Se la differenza oraria è maggiore di X (scusate non ricordo cosa X è fuori mano) verrà stampato un avviso e l'ora non sarà sincronizzata. Puoi controllare i tuoi messaggi syslog per i casi di questo.

In questo caso, interrompere NTP, eseguire l'host ntpdate e riavviare l'NTPD, ciò forzerà una sincronizzazione temporale, quindi inizierà a mantenerlo sincronizzato andando avanti, se si continua a spostarsi così tanto che si potrebbe avere un problema hardware.

Le colonne "reach" essendo 0 indicano che non era in grado di parlare con i server, ma a volte viene spostato gradualmente i bit per mostrare come sono andati gli ultimi 8 tentativi (quindi 377 è buono, 0 è cattivo).