El servicio chrony no cambia la hora
La idea errónea a menudo es que el servicio chrony está ajustando la hora a la proporcionada por el servidor NTP. Esto es incorrecto; lo que realmente sucede es que, según la respuesta del servidor NTP, chrony simplemente le dice al reloj del sistema que vaya más rápido o más lento. Por esta razón, a veces, aunque la hora sea incorrecta y el servidor NTP esté funcionando, la hora no se corrige inmediatamente.
Única hora cuando chrony establece la hora
Cuando se inicia el servicio chrony, hay algunas configuraciones en /etc/chrony/chrony.conf archivo que le dice que realmente establezca la hora si ocurren condiciones específicas:
# Force system clock correction at boot time. makestep 1000 10
lo que significa que si el chrony detecta durante las primeras 10 mediciones después de su inicio que la hora está desfasada en más de 1000 segundos, configurará el reloj.
Algunos comandos útiles
A continuación se muestran algunos comandos útiles que se pueden usar para solucionar problemas relacionados con chrony.
# chronyc tracking # chronyc sources # chronyc sourcestats # systemctl status chronyd # chronyc activity # timedatectl
Verificar el estado de cronyd
Para comprobar el estado del demonio 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. El comando de fuentes de chronyc
Ejecutando fuentes de chronyc -v muestra el estado actual del/los servidor/es NTP configurados en el sistema. Aquí hay un resultado de ejemplo, en el que ntp.example.com se muestra como un servidor válido que está en línea:
# 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
Tenga en cuenta que un estado de origen diferente a '*' generalmente indica un problema con el servidor NTP.
El estado de origen '~' significa que el tiempo es demasiado variable
Si el estado de origen es '~ ', probablemente significa que el servidor es accesible pero el tiempo es demasiado variable. Esto puede suceder si el servidor responde demasiado lento o responde a veces más lento ya veces más rápido. Puede verificar el tiempo de respuesta de los pings al servidor para ver si son lentos o variables. Este estado también se ha notado cuando el servidor se ejecuta en máquinas virtuales que son demasiado lentas y causan problemas de tiempo.
Chrony revisa y reinicia cada hora
Una vez por hora, el servicio chrony comprueba la salida de las fuentes chronyc -v comando, ejecutando el script /usr/sbin/palladion_chrony_healthcheck que ejecuta /usr/sbin/palladion_check_chrony y comprueba su salida:
- si /usr/sbin/palladion_check_chrony devuelve 1, significa que no había una fuente en línea (ninguna fuente con estado de fuente ='*'), por lo que chrony se reinicia en un intento de reinicializar el estado del servidor
- si /usr/sbin/palladion_check_chrony devuelve 0, esto significa que todo está bien, no es necesario reiniciar chrony porque ya tiene una fuente en línea válida
# 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
Registros de cronología
Hay varios registros crony que se pueden usar para solucionar problemas. La mayoría de ellos se encuentran en /var/log/chrony/ . Tenga en cuenta que el archivo más reciente no siempre es el *.log. A veces sucede que incluso el archivo *.log.2 o *.log.3 son los más recientes. Aquí hay un ejemplo de una lista de archivos ordenados por el más reciente:
# 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 ............
Intente configurar solo un servidor NTP ingresando su dirección IP
Si hasta ahora ha estado usando dos o más servidores NTP (ya sea porque estaban configurados o porque ingresó un FQDN que se resuelve en diferentes direcciones IP), intente configurar un solo servidor NTP ingresando solo una dirección IP. Esto puede resolver su problema relacionado con NTP.
Rastreo de la comunicación con el servidor NTP
Para verificar dos veces si el servidor NTP responde o no, es posible rastrear el tráfico entre chrony y el servidor NTP durante un período de tiempo mientras se monitorea el servidor:
1. Inicie un seguimiento de pcap con tcpdump en el puerto NTP 123 y déjelo en ejecución hasta que aparezca el problema (ejecútelo en 'pantalla' o con 'nohup' para evitar que se detenga si se desconecta del comando de shell)
2 . Tan pronto como vuelva a aparecer el problema, obtenga un Diagnóstico del sistema que cubra todo el historial desde que configuró el servidor con el nombre DNS hasta que volvió a ocurrir la brecha. Si esto produce un archivo que es demasiado grande, simplemente obtenga el Diagnóstico del sistema para datos actuales y, además, copie todos los archivos de /var/log/chrony/, y todos los archivos llamados /var/log/syslog* . Recuerde detener el seguimiento que inició en el paso 1