Síntomas
El reloj rara vez se menciona en lo que realmente se ve. En su lugar, los síntomas llegan a todo lo que depende de dos sistemas que coincidan en la hora.
- Los usuarios no pueden iniciar sesión o las sesiones terminan antes de lo esperado.
- GitHub Connect no se puede conectar o la página de licencia devuelve un error de servidor.
- GitHub Actions los trabajos no se inician o los tokens se rechazan como no válidos.
/var/log/github/exceptions.logcontiene errores sobre una declaración de expiración del token demasiado lejana en el futuro, como'Expiration time' claim ('exp') is too far in the future.- Las marcas de tiempo de la interfaz web, en los registros o en las confirmaciones no coinciden con el tiempo esperado.
Un token firmado por una instancia cuyo reloj es incorrecto parece no válido para el sistema que lo recibe, aunque nada está mal con el propio token. Por eso estos errores apuntan a la autenticación en lugar de al tiempo.
Causas
GitHub Enterprise Server mantiene la precisión de su reloj mediante la sincronización con los servidores del Protocolo de tiempo de red (NTP) a través del puerto UDP 123. Debe alcanzar al menos uno de ellos, continuamente.
Un servidor configurado deja de ser accesible por motivos ordinarios.
- Un firewall o un grupo de seguridad bloquea el puerto UDP de salida 123, algo fácil de pasar por alto porque el resto de la instancia funciona.
- Se retira o se cambia el nombre de un servidor de hora interno y la instancia sigue apuntando a la dirección antigua.
- El nombre de equipo ya no se puede resolver.
- Solo se configura un servidor, por lo que no hay nada a lo que recurrir cuando desaparece.
Cuando no se puede acceder a ningún servidor configurado, chrony sigue ejecutando el reloj del sistema local sin ninguna corrección externa, informando del estrato de reserva de 10 que GitHub Enterprise Server configura. Este no es el reloj de hardware, que es un dispositivo independiente administrado fuera de la chrony.
No falla nada en ese momento y no se genera ningún error. El reloj deja de corregirse y se desfasa, lentamente al principio, hasta que algo que depende de un tiempo preciso falla. Cuanto mayor sea la desviación, más amplios son los fallos.
Un hipervisor que también intenta establecer el reloj de la máquina virtual puede producir el mismo resultado al entrar en conflicto con la propia sincronización de la instancia.
Confirmando el problema
-
Acceda por SSH al shell administrativo. Para obtener más información, vea Acceder al shell administrativo (SSH).
-
Enumerar los orígenes de hora y su estado.
sudo chronyc sources -vLea la
MScolumna a la izquierda de cada fuente. Un?significa que chrony no está usando esa fuente. Por sí solo, eso no es una prueba de un problema de red, porque el mismo marcador aparece para un servidor que no está sincronizado, y para un origen que aún no ha proporcionado suficientes medidas.Lo que identifica un origen inaccesible es la evidencia de apoyo en la misma línea. En la salida siguiente,
Reaches0, lo que significa que ninguna de las consultas recientes recibió respuesta, yLastRxes-, lo que significa que nunca ha llegado ninguna muestra. Ninguno de los servidores ha respondido nunca.MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== ^? ntp1.example.com 0 10 0 - +0ns[ +0ns] +/- 0ns ^? ntp2.example.com 0 10 0 - +0ns[ +0ns] +/- 0nsSi un origen está marcado como
*, chrony lo ha seleccionado, lo que descarta el problema de accesibilidad. No confirma que el reloj sea preciso, ya que chrony corrige un desplazamiento grande gradualmente y la instancia puede estar muy alejada de la hora real mientras lo hace. Continúe con las comprobaciones restantes de cualquier manera. -
Compruebe a qué se sincroniza realmente la instancia.
sudo chronyc trackingUn identificador de referencia con un nombre vacío entre corchetes, junto con un estrato de
10, significa que la instancia ha renunciado a sus servidores configurados y usa su propio reloj.Reference ID : 7F7F0101 () Stratum : 10 System time : 0.000000000 seconds fast of NTP timeEl estrato cuenta a cuántos pasos está la instancia de un reloj de referencia, y una instancia siempre notifica uno más que el servidor que sigue. El valor de
10es específico: es el valor de reserva que GitHub Enterprise Server configura para cuando no hay ningún origen disponible, por lo que verlo junto con un identificador de referencia sin nombre es la señal.En su lugar, una instancia correcta indica el nombre del servidor al que sigue e informa de un estrato por encima del de ese servidor.
Reference ID : D9723B03 (ntp1.example.com) Stratum : 3 System time : 0.000079420 seconds fast of NTP time
System time se mide con respecto a los servidores que la instancia sigue, por lo que cuando sigue su propio reloj, el valor no tiene sentido. Marca un valor cercano a cero, independientemente de cuánto se haya desviado el reloj.
-
Mida el desfase por sí mismo comparando el reloj de instancia con un origen de confianza.
date -uTenga en cuenta cuánto se desvía. Una gran diferencia confirma que el reloj se ha desfasado sin supervisión.
-
Si desea obtener los detalles auxiliares de cada origen, por ejemplo, qué grado de asimetría tiene y cuántos ejemplos se han mantenido, use el siguiente comando.
sudo chronyc sourcestats -v
Resolución del problema
Restaure primero la sincronización y corrija el desfase que se creó mientras estuvo perdida. Corregir el desfase sin corregir la alcanzabilidad solo le compra tiempo antes de que vuelva a aparecer.
-
Compruebe con qué servidores está configurada la instancia, en la sección "Hora" de la Consola de administración. Para obtener más información, vea Configuración de la sincronización de la hora.
-
Confirme que la instancia puede acceder a ellos. El puerto UDP de salida 123 debe estar abierto hacia cada servidor, en cada firewall y grupo de seguridad entre la instancia y el servidor. Para obtener más información, vea Puertos de red.
-
Si un servidor ha desaparecido o la instancia no puede abrir la ruta de acceso a él, configure los servidores a los que puede acceder la instancia. Configure al menos dos, de modo que, si uno falla o deja de estar disponible, no deje la instancia sin nada.
-
Confirme que chrony ha seleccionado de nuevo una fuente. Ahora uno de ellos debe marcarse
*, con un valor distinto de ceroReach.sudo chronyc sources -v -
Corrija el desfase que se creó mientras la instancia no estaba sincronizada. NTP corrige pequeñas discrepancias por sí solo, pero una gran diferencia necesita el siguiente comando. Para obtener más información, vea Configuración de la sincronización de la hora.
sudo chronyc -a makestep -
Confirme que el reloj ahora coincide con una fuente de confianza. Esta es la comprobación que indica que el desfase realmente ha desaparecido, en lugar de que aún se esté corrigiendo.
date -u -
Vuelva a intentar lo que estuviera fallando.
Prevenir la recurrencia
- Configure al menos dos servidores de tiempo, para que la pérdida de uno no detenga la sincronización.
- Después de cambiar los servidores, compruebe que la instancia puede conectarse a ellos. Un servidor configurado no es necesariamente uno en funcionamiento y nada le advierte cuando deja de responder.
- Mantenga abierto el puerto UDP de salida 123 a los servidores de hora cuando cambien las reglas del firewall.
- Impida que el hipervisor establezca el reloj de la máquina virtual, para que no compita con la sincronización propia de la instancia. Para obtener más información, consulte la documentación proporcionada por el proveedor de virtualización.
- Compruebe la fuente de hora como parte de las comprobaciones de estado rutinarias. El desfase es inofensivo hasta que deja de serlo, y detectarlo cuando aún es reducido le ahorra tener que averiguar cuál de varios fallos no relacionados proviene del reloj.
Contactar con Soporte de GitHub
Si la instancia todavía no puede llegar a un servidor de hora después de haber comprobado la configuración y la ruta de acceso de red, o si los síntomas originales continúan una vez que el reloj es preciso, póngase en contacto con Soporte de GitHub en lugar de continuar. Para obtener más información, vea Crear un ticket de soporte.
Si ya ha abierto una incidencia, adjuntar un paquete de soporte técnico ayuda a Soporte de GitHub diagnosticar el problema más rápido. Para obtener más información, vea Proporcionar datos al soporte técnico de GitHub.