Perché ntpd non aggiorna l'ora sul mio server?

Ho ntpd in esecuzione sul mio server. Sono tutte le impostazioni predefinite, tranne che ho commentato la sua capacità di essere un server per altre macchine:

# restrict -4 default kod notrap nomodify nopeer noquery                                                                    
# restrict -6 default kod notrap nomodify nopeer noquery   
restrict default ignore

Se corro ntpdate -q ntp.ubuntu.com, mi viene detto che l'orologio della mia macchina è spento di 7 secondi.

Cosa sta succedendo? Come posso diagnosticare cosa sta succedendo, c'è un registro che posso attivare?

maggiori informazioni # 1

# ntpq -np
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 91.189.94.4     193.79.237.14    2 u   30   64    7  108.518   -0.136   0.361

maggiori informazioni # 2

Ecco come appariva quando ho posto la domanda:

# ntpdate -q ntp.ubuntu.com
server 91.189.94.4, stratum 2, offset 7.191308, delay 0.13310
10 Jan 20:38:09 ntpdate[31055]: step time server 91.189.94.4 offset 7.191308 sec

Ed ecco come appare ora, dopo aver riavviato ntpd un paio di volte (suppongo che sia quello che l'ha risolto):

# ntpdate -q ntp.ubuntu.com
server 91.189.94.4, stratum 2, offset 0.000112, delay 0.13164
10 Jan 20:47:03 ntpdate[31419]: adjust time server 91.189.94.4 offset 0.000112 sec

maggiori informazioni # 3

Ho disinstallato ntp e installato openntpd ed eseguito /usr/sbin/ntpd -d, e vedo l'output in questo modo:

reply from 64.73.32.134: offset 6.715003 delay 0.041152, next query 30s
reply from 208.53.158.34: offset 6.700224 delay 0.036263, next query 31s
adjusting local clock by 6.734120s
reply from 72.18.205.156: offset 6.708575 delay 0.035885, next query 30s
reply from 64.73.32.134: offset 6.701463 delay 0.044199, next query 33s

Il che per me indica abbastanza chiaramente che non sono in grado di impostare l'ora sul mio server (anche se, con ntp normale, a volte sembra aggiornarsi ...).

maggiori informazioni # 4

Il mio provider VPS dice:

I kernel più recenti non dovrebbero bloccare il tuo sistema sul nostro orologio dom0, per essere al sicuro puoi impostare xen.independent_wallclock = 1 nel tuo sysctl.conf.

Suppongo che non affronti ancora il problema del VPS che necessita di una CPU disponibile per eseguire i calcoli di temporizzazione corretti.

È possibile abilitare la registrazione in ntpd aggiungendo questo a ntp.conf:

logfile /var/log/ntpd.log

Fonte: manuale ntp

Se si disattiva ntpd, è possibile aggiornare l'orologio dalla riga di comando? Se si esegue il comando ntpdate e si riceve un errore simile al seguente:

# ntpdate ntp.ubuntu.com
10 Jan 23:47:57 ntpdate[26284]: Can't adjust the time of day: Operation not permitted

Ciò significa che probabilmente sei su un VPS e in tal caso non puoi modificare l'orologio di sistema, ciò può essere fatto solo sul computer host.

Va bene gente, nel momento in cui ho posto questa domanda, ho reinstallato ntp con la configurazione del fornitore predefinito (Ubuntu 10.0.4) e l'ho fatta funzionare per alcuni giorni. Al momento della stesura di questo documento, ntpdate -q ntp.ubuntu.comdimostra che il mio tempo è preciso entro 0,000216 secondi. Quindi, i problemi che stavo avendo devono essere stati con la mia configurazione personalizzata (dove stavo cercando di rendere impossibile agli host esterni di interrogare il mio server, cosa che sto già facendo con il mio firewall, quindi non sono troppo preoccupato). Ecco Ubuntu 10.0.4 ntp.conf nella sua interezza, con i commenti rimossi:

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 ntp.ubuntu.com

restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery

restrict 127.0.0.1
restrict ::1

Accolgo con favore il feedback su come questa configurazione potrebbe essere migliorata.

Ho anche fatto un biglietto con il mio provider VPS chiedendo loro una raccomandazione dettagliata sulla cosa migliore da fare. Li ho indicati su questo thread e su qualche altra documentazione che indica che forse l'allocazione della CPU avrebbe causato un problema di temporizzazione. Ecco cosa hanno detto:

I kernel più recenti non dovrebbero bloccare il tuo sistema sul nostro orologio dom0, per essere al sicuro puoi impostare xen.independent_wallclock = 1 nel tuo sysctl.conf. Ciò assicurerà che l'istanza del server non segua l'orologio sul server host.

e:

Penso che potresti capire male fino a che punto questo problema riguarda i client NTP in un ambiente virtualizzato. Nella mia esperienza su un sistema virtualizzato su un host Xen (come la nostra configurazione su Rackspace Cloud), l'imprecisione ereditata dal non avere un clock di sistema dedicato per elaborare gli interrupt equivale a frazioni di secondo, anche su sistemi altamente caricati. Questa leggera inesattezza è facilmente gestita da NTP anche se è impostata per aggiornare l'ora dei server una volta al giorno (o anche meno frequentemente).

Uno dei tuoi commenti dice che sei in esecuzione su un vhost. In questo caso, probabilmente non avrai molto successo perché il senso del tempo del tuo vhost dipenderà sia dal vero host su cui è in esecuzione sia da quanto sia occupato nel complesso il vhost.

A seconda della virtualizzazione utilizzata, il vhost potrebbe non ottenere una quota costante di interruzioni in un determinato periodo di tempo. Questo renderà l'orologio più veloce o più lento di quello che sta realmente accadendo. Poiché ntp sta cercando di misurare i cambiamenti partendo dal presupposto che il tuo orologio è a velocità fissa più veloce o più lento rispetto al resto del mondo, questo accelerare e rallentare darà adattamenti ntp e probabilmente alla fine si arrenderà, con il risultato che ntp -npmostra i time server che ntp ha ritenuto non idonei.

La tua scommessa migliore in questo caso è probabilmente una forza bruta rdate -s $serverogni tanto (come ogni sei ore) per trascinare l'orologio dal naso in modo che non si discosti eccessivamente dalla sincronizzazione. Ma la precisione granulosa è probabilmente fuori portata.

Cose che ho trovato in passato, quando ho usato ntpd invece di openntpd:

1. È necessario consentire l'accesso a localhost affinché ntpd si avvii correttamente e faccia effettivamente cose

   restrict 127.0.0.1
   restrict ::1
   

2. Sebbene sia possibile utilizzare i nomi host per le regole del server, aprire back-up dei fori per parlare con quei server significa utilizzare ciò restrictche richiede indirizzi IP, quindi alla fine ho dovuto usare gli IP per tutto.

3. Non menzionate l'utilizzo restrictper aprire il backup di accesso ai vostri server. Questo è un problema. Prova blocchi come i seguenti:

   # ntp.xs4all.nl
   server          194.109.22.18
   restrict        194.109.22.18
   

4. Sono necessari più peer o server per ntpd, dal momento che tenta di utilizzare il voto a maggioranza per affrontare un cattivo attore. Quindi un minimo di 4, per essere ancora in grado di avere la maggioranza quando ne perdi una, preferibilmente 5.

5. Per bloccare l'accesso predefinito, potrei usare:

   restrict default notrust nomodify
   

   così da essere ancora in grado di interrogare, ma ho finito per usare restrict default ignorecome fai quando ntpd 4.2 ha cambiato il significato di notrust. sospiro

6. Se non stai fornendo un servizio a tempo ad altri, probabilmente non hai bisogno della piena potenza del normale ntpd e dovresti openntpdinvece prendere in considerazione . Scritto dall'equipaggio OpenBSD, è un'implementazione molto più minimale, usando la separazione dei privilegi e un file di configurazione molto più semplice. Presumibilmente non fornirà il tempo estremamente preciso che ntpd farà, ma è facilmente abbastanza buono per un normale server o workstation.

• Se ntpd non fosse in grado di connettersi con il server remoto, non vedresti un offset per quel server.
• Se ntpq fosse bloccato da ntpd, vedresti un chiaro messaggio di errore da ntpq.
• Se qualche altro servizio imposterà anche il tempo (come gli strumenti di VMware), vedresti un offset di salto per il server (esegui ntpq -p ogni 70 secondi).

L' reach 7output in ntpq ha indicato che si lascia funzionare ntpd solo per circa 4 minuti. 7 è 111 binario, il che significa che il server è stato raggiunto già 3 volte. ntp raggiunge ogni 64 secondi ( pollvalore) e ha atteso già 30 secondi ( whenvalore) dall'ultimo contatto.

Il offset -0.136indicato, che il sistema è già sincronizzato. Solo ntpd non ha ancora contrassegnato il server come sorgente. Dagli solo più tempo e apparirà una piccola stella.

Quindi, in realtà il tuo NTTP era in fase di sincronizzazione. Ma ntpd di solito non si sincronizza in un unico grande salto (come ntpdate), ma cerca di regolare il tempo lentamente e garantisce in diversi cicli che il tempo sia stabile.

PS: sono consapevole che la domanda è molto antica. Ma il problema è senza tempo. E tutte le altre risposte sono solo IMHO fuorviante. VMWare consiglia persino ntpd di mantenere il tempo sincronizzato.

Ho trovato il mio sistema spento e perplesso perché l'orologio HW non si sincronizzava con l'orologio di sistema su un arresto pulito. Sembra che ci sia un'impostazione NTP in sysconfig che deve essere modificata per farlo accadere.

In /etc/sysconfig/ntpd:

# Set to 'yes' to sync hw clock after successful ntpdate
SYNC_HWCLOCK=no

L'ho impostato su yes. Naturalmente prima verifica di avere un server NTP solido e che l'orologio di sistema sia affidabile.

Sapevo che era così: il mio disallineamento era di 47 secondi e anche il mio orologio HW era di 47 secondi. Bingo! Il mio primo indizio sono stati i guasti di Kerberos nei registri. Kerberos e molti NAS non funzioneranno se l'inclinazione dell'orologio è troppo grande.

Buona giornata!

se stai eseguendo vhost su vmware controlla il seguente articolo ... potrebbe aiutarti http://www.vmware.com/files/pdf/Timekeeping-In-VirtualMachines.pdf

Hai ..

Dai un'occhiata a questo riferimento per vedere se può aiutarti a risolvere il problema:

http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_: Ch24 : _The_NTP_Server

potresti voler pubblicare il contenuto del tuo file ntpd.conf, l'output dei comandi di debug come ntpq -p

E controlla la tua data / ora?

E verifica anche questo, esegui ntpdate e avvia ntpd, il tempo è sincronizzato?

con i migliori auguri