Probabili cause di morte inaspettata di NTPD e soluzioni

9

In un'applicazione Web che utilizza s3 per l'archiviazione di documenti fisici, stiamo riscontrando problemi con l'NTP che muore continuamente. Questo sembra accadere all'incirca una o due volte al giorno. Ci sono pochissime informazioni fornite in questo caso, a parte il fatto che esiste il file PID ma il servizio è morto quando controllo lo stato.

Qualcuno può suggerire probabili cause di morte di NTPD? Sto supponendo che forse la deriva dell'orologio lo sta causando la morte, ma non sono sicuro di cosa potrebbe causare neanche quello. C'è più che sufficiente memoria e spazio disponibile su disco.

L'ultima volta che il servizio è morto, questo è stato l'output:

Sep  6 06:15:25 vm02 rsyslogd: [origin software="rsyslogd" swVersion="5.8.10" x-pid="988" x-info="http://www.rsyslog.com"] rsyslogd was HUPed
Sep  6 06:17:06 vm02 ntpd[10803]: 0.0.0.0 0618 08 no_sys_peer
Sep  6 08:01:10 vm02 ntpd[10803]: 0.0.0.0 0617 07 panic_stop -28101 s; set clock manually within 1000 s.

— user275940
fonte

Quale sistema operativo e versione? C'è un nascondiglio in esecuzione? Quanti server ntp sono configurati? Quali opzioni ntpd sono attive?

— Nils,

Potresti provare a rimuovere il tuo file ntp.drift, il suo valore potrebbe essere troppo alto e causare l'inclinazione

— Rqomey

6

Direi che non esiste un metodo di 1 minuto per trovare il motivo esatto.

Abbiamo avuto problemi simili in precedenza nel nostro ambiente ESXi. Per farla breve, abbiamo scoperto che l'orologio dell'host ESXi si è spostato molto e le VM guest stavano sincronizzando il tempo sia dall'host ESXi che dal server NTP upstream. Ciò ha causato confusione di NTPd su VM, quindi è morto abbastanza spesso.

Abbiamo anche riscontrato in alcuni rari casi che la perdita di pacchetti casuali ha causato anche la chiusura di NTPd perché il tempo di andata e ritorno tra il server e il server NTPd upstream viene utilizzato per calcolare il tempo di deriva.

In due casi precedenti, se NTPd rileva una notevole deriva temporale, ad esempio più di 1000 secondi, si chiude automaticamente. -g opzione aiuterà un po '.

   -g      Normally,  ntpd  exits  with  a  message to the system log if the offset exceeds the panic threshold,
           which is 1000 s by default. This option allows the time to be set to any value  without  restriction;
           however,  this  can  happen only once. If the threshold is exceeded after that, ntpd will exit with a
           message to the system log. This option can be used with the -q and -x options. See the tinker command
           for other options.

Puoi dare un'occhiata al registro di sistema , che dovrebbe contenere alcune parole potrebbe darti un suggerimento. È inoltre possibile monitorare l'output "ntpq -p" per avere un'idea approssimativa di come si sviluppa l'offset.

— Enzo Wang
fonte

Quando esegui ntpd su VM, non dovresti anche sincronizzare l'ora con l'host e non dovresti includere l'orologio locale come riferimento.

— Paul Gear,

3

Il messaggio di registro indica chiaramente che la deriva dell'orologio è la ragione dell'uscita. Possibili soluzioni:

Inizia ntpd con il flag -g; tuttavia, ciò non risolverà la causa principale, che è l'orologio inclinato.
Esegui ntpdate prima di avviare ntpd; probabilmente lo stesso avvertimento.

Aggiungi più fonti di tempo; NTP ha bisogno di 4-6 fonti per mantenere una buona precisione. Un modo semplice per farlo è includere riferimenti ripetuti a [0-3] .YOURREGION.pool.ntp.org nella tua configurazione, ad es.

server 0.au.pool.ntp.org iburst
server 1.au.pool.ntp.org iburst
server 2.au.pool.ntp.org iburst
server 3.au.pool.ntp.org iburst

server 0.au.pool.ntp.org iburst
server 1.au.pool.ntp.org iburst
server 2.au.pool.ntp.org iburst
server 3.au.pool.ntp.org iburst

— Paul Gear
fonte

1

Un'altra opzione che puoi provare è chrony. Nei nostri test ha prestazioni più stabili di ntpd e gestisce meglio il disallineamento temporale sperimentato negli ambienti virtuali.

http://chrony.tuxfamily.org/

— Jokajak
fonte