Descompasso do relógio devido a servidores NTP inacessíveis

Quando sua instância do GitHub Enterprise Server não consegue alcançar os servidores de tempo para os quais está configurado, seu relógio se afasta do tempo real. O login, as integrações e GitHub Actions podem então falhar por motivos que nunca mencionam o relógio.

Neste artigo

Symptoms

O relógio raramente é mencionado no que você realmente vê. Os sintomas, em vez disso, afetam tudo o que depende de dois sistemas estarem sincronizados quanto ao horário.

  • Os usuários não podem entrar ou as sessões terminam mais cedo do que o esperado.
  • GitHub Connect falha ao se conectar ou a página de licença retorna um erro de servidor.
  • GitHub Actions os trabalhos não são iniciados ou os tokens são rejeitados como inválidos.
  • /var/log/github/exceptions.log contém erros sobre uma declaração de expiração do token estar muito no futuro, como 'Expiration time' claim ('exp') is too far in the future.
  • Carimbos de data/hora na interface da Web, em logs ou em commits não correspondem ao tempo esperado.

Um token assinado por uma instância cujo relógio está errado parece inválido para o sistema que o recebe, mesmo que nada esteja errado com o próprio token. É por isso que essas falhas apontam para a autenticação em vez do horário.

Causas

GitHub Enterprise Server mantém seu relógio preciso sincronizando com servidores NTP (Protocolo de Tempo de Rede) pela porta UDP 123. Ele precisa chegar a pelo menos um deles, continuamente.

Um servidor configurado deixa de ser acessível por razões normais.

  • Um firewall ou grupo de segurança bloqueia a porta UDP de saída 123, o que é fácil de perder porque o restante da instância funciona.
  • Um servidor de tempo interno é desativado ou renomeado e a instância ainda é apontada para o endereço antigo.
  • O nome do host não resolve mais.
  • Apenas um servidor está configurado, portanto, não há nada a que recorrer quando ele desaparecer.

Quando nenhum servidor configurado pode ser alcançado, o chrony continua operando com o relógio do sistema local sem correção externa, relatando o estrato de fallback 10 que GitHub Enterprise Server configura. Esse não é o relógio de hardware, que é um dispositivo separado gerenciado fora do chrony.

Nada falha nesse momento e nenhum erro é gerado. O relógio deixa de ser corrigido e descompassa, lentamente no início, até que algo que dependa de tempo preciso falhe. Quanto maior o desvio, mais amplas as falhas.

Um hipervisor que também tenta definir o relógio da máquina virtual pode produzir o mesmo resultado, ao entrar em conflito com a sincronização da própria instância.

Confirmando o problema

  1. Conecte-se ao shell administrativo via SSH. Para obter mais informações, consulte Acessar o shell administrativo (SSH).

  2. Liste as fontes de tempo e seu estado.

    sudo chronyc sources -v

    Leia a MS coluna à esquerda de cada origem. Um ? significa que o chrony não está usando essa fonte. Por si só, isso não é uma prova de um problema de rede, pois o mesmo marcador aparece para um servidor que está em si não sincronizado e para uma fonte que ainda não forneceu medidas suficientes.

    O que identifica uma fonte inacessível é a evidência comprobatória na mesma linha. Na saída abaixo, Reach é 0, o que significa que nenhuma das sondagens recentes recebeu uma resposta, e LastRx é -, o que significa que nenhuma amostra jamais chegou. Nenhum servidor respondeu.

    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] +/-    0ns

    Se uma fonte estiver marcada *, o chrony a selecionou, o que exclui o problema de alcançabilidade. Ele não confirma se o relógio é preciso, pois o chrony corrige um deslocamento grande gradualmente e a instância pode estar bem fora do tempo real enquanto o faz. Prossiga com as verificações restantes de qualquer forma.

  3. Verifique com o que a instância está realmente sincronizada.

    sudo chronyc tracking

    Uma ID de referência com um nome vazio entre colchetes, juntamente com um estrato de 10, significa que a instância desistiu de seus servidores configurados e está usando seu próprio relógio.

    Reference ID    : 7F7F0101 ()
Stratum         : 10
System time     : 0.000000000 seconds fast of NTP time

    Stratum conta quantas etapas a instância está de um relógio de referência e uma instância sempre relata uma a mais do que o servidor que ela segue. O valor de 10 é específico: é o fallback que GitHub Enterprise Server configura para quando nenhuma origem está disponível, portanto, vê-lo junto com uma ID de referência sem nome é o sinal.

    Uma instância saudável nomeia o servidor que está seguindo em vez disso e relata um estrato um nível acima do desse servidor.

    Reference ID    : D9723B03 (ntp1.example.com)
Stratum         : 3
System time     : 0.000079420 seconds fast of NTP time

System time é medido em relação aos servidores que a instância está seguindo, portanto, quando está seguindo seu próprio relógio, o valor não tem sentido. A leitura fica próxima de zero, não importa o quão longe o relógio se desviou.

  1. Meça o desvio por si mesmo comparando o relógio da instância com uma fonte em que você confia.

    date -u

    Observe o quanto está fora. Uma grande diferença confirma que o relógio tem apresentado deriva sem controle.

  2. Se você quiser os detalhes complementares de cada fonte, como o grau de assimetria e quantas amostras foram mantidas, use o comando a seguir.

    sudo chronyc sourcestats -v

Resolvendo o problema

Restaure a sincronização primeiro e, em seguida, corrija o descompasso acumulado enquanto a sincronização esteve perdida. Corrigir o descompasso sem corrigir a alcançabilidade só lhe dá tempo antes de retornar.

  1. Verifique em quais servidores a instância está configurada, na seção "Time" do Console de Gerenciamento. Para obter mais informações, consulte Configurar a sincronização de hora.

  2. Confirme se a instância pode alcançá-las. A porta UDP de saída 123 deve estar aberta para cada servidor, em cada firewall e grupo de segurança entre a instância e o servidor. Para obter mais informações, consulte Portas de rede.

  3. Se um servidor tiver sumido ou você não puder abrir o caminho para ele, configure os servidores que a instância pode acessar. Configure pelo menos dois, para que, se um ficar indisponível, não deixe a instância sem nada.

  4. Confirme se chrony selecionou uma fonte novamente. Um deles agora deve ser marcado *, com um Reach diferente de zero.

    sudo chronyc sources -v

  5. Corrija o descompasso que se acumulou enquanto a instância não estava sincronizada. O NTP corrige pequenas discrepâncias por conta própria, mas uma grande diferença precisa do comando a seguir. Para obter mais informações, consulte Configurar a sincronização de hora.

    sudo chronyc -a makestep

  6. Confirme se o relógio agora está sincronizado com uma fonte em que você confia. Esta é a verificação que informa que o descompasso realmente desapareceu, em vez de ainda estar sendo corrigido.

    date -u

  7. Tente novamente o que estava falhando.

Como evitar a recorrência

  • Configure pelo menos dois servidores de tempo, para que perder um não interrompa a sincronização.
  • Depois de alterar os servidores, verifique se a instância pode realmente alcançá-los. Um servidor configurado não é necessariamente um servidor funcional e nada avisa quando ele para de responder.
  • Mantenha a porta UDP de saída 123 aberta para seus servidores de tempo quando as regras de firewall forem alteradas.
  • Impeça o hipervisor de definir o relógio da máquina virtual, para que ele não concorra com a sincronização da própria instância. Para obter mais informações, consulte a documentação fornecida pelo seu provedor de virtualização.
  • Verifique a origem do horário como parte de suas verificações rotineiras de integridade. A deriva é inofensiva até que deixe de ser, e pegá-la enquanto ainda é pequena evita que você tenha de descobrir qual das várias falhas não relacionadas veio do relógio.

Entrar em contato com Suporte do GitHub

Se a instância ainda não conseguir alcançar um servidor de tempo depois de verificar a configuração e o caminho da rede, ou se os sintomas originais continuarem quando o relógio estiver correto, contate Suporte do GitHub em vez de continuar. Para obter mais informações, consulte Criando um tíquete de suporte.

Se você já abriu um tíquete, anexar um pacote de suporte ajuda a Suporte do GitHub diagnosticar o problema mais rapidamente. Para obter mais informações, consulte Fornecendo dados para GitHub suporte.

Leitura adicional