Il servizio chrony non cambia l'ora
L'idea sbagliata spesso è che il servizio chrony stia impostando l'ora su quella fornita dal server NTP. Questo non è corretto:ciò che effettivamente accade è che, in base alla risposta del server NTP, chrony dice semplicemente all'orologio di sistema di andare più veloce o più lento. Per questo motivo, a volte, anche se l'ora è sbagliata e il server NTP funziona, l'ora non viene corretta immediatamente.
Solo quando chrony imposta l'ora
All'avvio del servizio chrony, ci sono alcune impostazioni in /etc/chrony/chrony.conf file che gli dice di impostare effettivamente l'ora se si verificano condizioni specifiche:
# Force system clock correction at boot time. makestep 1000 10
il che significa che se chrony rileva durante le prime 10 misurazioni dopo il suo inizio che l'ora è disattivata di oltre 1000 secondi imposterà l'orologio.
Alcuni comandi utili
Di seguito sono riportati alcuni comandi utili che possono essere utilizzati per la risoluzione dei problemi relativi a Chrony.
# chronyc tracking # chronyc sources # chronyc sourcestats # systemctl status chronyd # chronyc activity # timedatectl
Controlla lo stato di chronyd
Per controllare lo stato del demone chronyd:
# systemctl status -l chronyd
● chronyd.service - NTP client/server
Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2016-08-12 13:22:22 IST; 1s ago
Process: 33263 ExecStartPost=/usr/libexec/chrony-helper update-daemon (code=exited, status=0/SUCCESS)
Process: 33259 ExecStart=/usr/sbin/chronyd $OPTIONS (code=exited, status=0/SUCCESS)
Main PID: 33261 (chronyd)
CGroup: /system.slice/chronyd.service
└─33261 /usr/sbin/chronyd
Aug 12 13:22:22 NVMBD1S11BKPMED03 systemd[1]: Starting NTP client/server...
Aug 12 13:22:22 NVMBD1S11BKPMED03 chronyd[33261]: chronyd version 2.1.1 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +DEBUG +ASYNCDNS +IPV6 +SECHASH)
Aug 12 13:22:22 NVMBD1S11BKPMED03 chronyd[33261]: Frequency 0.000 +/- 1000000.000 ppm read from /var/lib/chrony/drift
Aug 12 13:22:22 NVMBD1S11BKPMED03 systemd[1]: Started NTP client/server. Il comando delle sorgenti cronologiche
Esecuzione di sorgenti cronologiche -v mostra lo stato corrente del/i server NTP configurato nel sistema. Ecco un esempio di output, in cui ntp.example.com viene mostrato come un server valido che è online:
# chronyc sources -v 210 Number of sources = 1 .-- Source mode '^' = server, '=' = peer, '#' = local clock. / .- Source state '*' = current synced, '+' = OK for sync, '?' = unreachable, | / 'x' = time may be in error, '~' = time is too variable. || .- xxxx [ yyyy ] +/- zzzz || / xxxx = adjusted offset, || Log2(Polling interval) -. | yyyy = measured offset, || | zzzz = estimated error. || | | MS Name/IP address Stratum Poll LastRx Last sample ============================================================================ ^* ntp.example.com 3 6 40 +31us[ -98us] +/- 118ms
Tieni presente che uno stato di origine diverso da "*" di solito indica un problema con il server NTP.
Stato sorgente '~' significa che l'ora è troppo variabile
Se lo stato della sorgente è "~ ', probabilmente significa che il server è accessibile ma il tempo è troppo variabile. Ciò può verificarsi se il server risponde troppo lentamente o risponde a volte più lentamente ea volte più velocemente. Puoi controllare il tempo di risposta dei ping al server per vedere se sono lenti o variabili. Questo stato è stato notato anche quando il server è in esecuzione su macchine virtuali che sono troppo lente causando problemi di temporizzazione.
Chrony controlla e riavvia ogni ora
Una volta ogni ora, il servizio chrony controlla l'output delle fonti chronyc -v comando, eseguendo lo script /usr/sbin/palladion_chrony_healthcheck che esegue /usr/sbin/palladion_check_chrony e ne controlla l'output:
- se /usr/sbin/palladion_check_chrony restituisce 1 – significa che non c'era alcuna fonte online (nessuna fonte con stato della fonte ='*'), quindi chrony si riavvia nel tentativo di reinizializzare lo stato del server
- se /usr/sbin/palladion_check_chrony restituisce 0 – significa che è tutto a posto, chrony non ha bisogno di essere riavviato perché ha già una fonte online valida
# cat /etc/cron.d/chrony SHELL=/bin/sh PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin # # Check chrony every hour and restart if necessary. # 16 * * * * root /usr/sbin/palladion_chrony_healthcheck
Registri Chrony
Esistono diversi registri cronologici che possono essere utilizzati per la risoluzione dei problemi. La maggior parte di essi si trova in /var/log/chrony/ . Si noti che il file più recente non è sempre quello *.log. A volte capita che anche i file *.log.2 o *.log.3 siano quelli più recenti. Ecco un esempio di elenco dei file con l'ordinamento in base al più recente:
# ls -lisaht /var/log/chrony/ total 1.5M 3801115 580K -rw-r--r-- 1 root root 574K Oct 21 14:56 measurements.log.3 3801131 544K -rw-r--r-- 1 root root 540K Oct 21 14:56 statistics.log.3 3801166 356K -rw-r--r-- 1 root root 350K Oct 21 14:56 tracking.log.3 3801089 4.0K drwxr-xr-x 16 root root 4.0K Oct 21 00:01 .. 3801114 4.0K drwxr-xr-x 2 root root 4.0K Oct 21 00:01 . 3801128 0 -rw-r--r-- 1 root root 0 Oct 21 00:01 tracking.log 3801110 0 -rw-r--r-- 1 root root 0 Oct 21 00:01 measurements.log 3801120 0 -rw-r--r-- 1 root root 0 Oct 21 00:01 statistics.log 3801167 0 -rw-r--r-- 1 root root 0 Oct 20 00:01 tracking.log.1 3801165 0 -rw-r--r-- 1 root root 0 Oct 20 00:01 statistics.log.1 3801159 0 -rw-r--r-- 1 root root 0 Oct 20 00:01 measurements.log.1 ............
Prova a impostare un solo server NTP inserendo il suo indirizzo IP
Se fino ad ora hai utilizzato due o più server NTP (o perché sono stati impostati o perché hai inserito un FQDN che risolve in indirizzi IP diversi), prova a impostare un unico server NTP inserendo un solo indirizzo IP. Questo potrebbe risolvere il tuo problema relativo a NTP.
Tracciamento della comunicazione con il server NTP
Per verificare se il server NTP risponde o meno, è possibile tracciare il traffico tra chrony e il server NTP per un periodo di tempo durante il monitoraggio del server:
1. Avvia una traccia pcap con tcpdump sulla porta NTP 123 e lasciala in esecuzione fino alla comparsa del problema (eseguila in 'screen' o con 'nohup' per evitare che venga interrotta se ti disconnetti dal comando della shell)
2 . Non appena il problema si ripresenta, ottieni una diagnostica di sistema che copre l'intera cronologia poiché hai impostato il server sul nome DNS fino a quando il divario non si è ripresentato. Se questo produce un file troppo grande, ottieni semplicemente la diagnostica di sistema per i dati correnti e in aggiunta copia tutti i file da /var/log/chrony/ e tutti i file chiamati /var/log/syslog* . Ricorda di interrompere la traccia che hai iniziato al passaggio 1