Como configurar NTP no Linux com Chrony

Já peguei ambiente com autoscaling operando transações e filas em que os números simplesmente não batiam. Um job agendado parecia atrasado, mensagens de fila chegavam em ordem estranha e a transação registrada numa máquina não combinava com a da outra. O primeiro comando que rodei foi date. A diferença de horário expôs o problema antes de qualquer diagnóstico sofisticado.

Esse é o ponto do Chrony: não é instalar um pacote para cumprir checklist. É manter o relógio estável para que logs, filas, jobs e transações contem a mesma história. Em ambientes que operei, a referência foi o Amazon Time Sync Service, com Chrony fazendo a disciplina do relógio. O objetivo era simples: nada de drift ou instabilidade.

Instalação rápida no Ubuntu

No Ubuntu, instale o Chrony e confirme que o serviço subiu:

sudo apt update
sudo apt install -y chrony
sudo systemctl enable --now chrony
systemctl status chrony --no-pager

Antes de alterar fontes Em instâncias EC2, confira o arquivo atual antes de trocar qualquer server ou pool. Misturar fontes com políticas diferentes de leap second é uma forma desnecessária de criar comportamento difícil de explicar.

Configurando a fonte de horário na AWS

Em instâncias EC2, a AWS recomenda o endpoint local do Amazon Time Sync Service. Ele é mais direto que o serviço público e deve permanecer como preferido. No Ubuntu 24.04, o arquivo é /etc/chrony/chrony.conf e já vem com quatro linhas pool apontando para ntp.ubuntu.com e para o ubuntu.pool.ntp.org; em outras distribuições, o caminho comum é /etc/chrony.conf.

# Antes de qualquer outra linha server/pool do arquivo
server 169.254.169.123 prefer iburst minpoll 4 maxpoll 4

Em instâncias Nitro com IPv6, a alternativa é server fd00:ec2::123 prefer iburst minpoll 4 maxpoll 4. Use um endpoint ou o outro, nunca os dois: a própria AWS avisa que os pacotes vêm do mesmo servidor local e que configurar ambos não melhora a precisão.

Depois de salvar, reinicie e valide. Numa EC2 bem configurada, a linha com ^* em chronyc sources -v é a do 169.254.169.123:

sudo systemctl restart chrony
chronyc sources -v
chronyc tracking
date

O marcador ^* em chronyc sources -v indica a fonte selecionada. Em chronyc tracking, procure Leap status: Normal e acompanhe Last offset, RMS offset e Root dispersion. Não existe um número universal que sirva para todo ambiente. O que importa é desvio consistente com a sua carga e ausência de variações inesperadas.

Não use o endpoint local da AWS fora da EC2 O endpoint local é exclusivo das instâncias EC2. Fora da EC2, use uma fonte apropriada para seu ambiente. A AWS disponibiliza time.aws.com como serviço público, mas recomenda a fonte local para instâncias EC2. Consulte a configuração atual da AWS antes de colar a linha server no arquivo.

Amazon Linux 2023: já vem configurado, e o arquivo engana

No Amazon Linux 2023 (e nas versões recentes do Amazon Linux 2), o Chrony já usa o Amazon Time Sync Service por padrão. Não há nada para instalar nem editar; o trabalho é conferir:

systemctl status chronyd --no-pager
chronyc sources -v | grep -F '^*'
chronyc tracking

O detalhe que pega quem vem do Ubuntu: o /etc/chrony.conf do AL2023 não tem nenhuma linha server ou pool. Ele só aponta para diretórios:

2:sourcedir /run/chrony.d
8:sourcedir /etc/chrony.d

As fontes são geradas no boot pelo chrony-config.service e gravadas em /run/chrony.d/. Quem roda grep server /etc/chrony.conf não acha nada e conclui que o NTP não está configurado, ou, pior, cola uma linha server por cima de uma configuração que já estava certa. Para trocar a fonte padrão, o caminho mais limpo é criar um arquivo .sources em /etc/chrony.d/: o script que gera as fontes (/usr/sbin/amazon-chrony-config) encerra sem fazer nada quando encontra um .sources não vazio ali, e sudo chronyc reload sources aplica sem reiniciar o daemon.

O README do AL2023 está desatualizado O /etc/chrony.d/README manda usar USE_AMAZON_NTP_ENDPOINTS=no em /etc/sysconfig/chrony. Na imagem que testei, esse arquivo nem existe: o script lê /etc/sysconfig/chronyd e a variável que ele consulta é USE_AMAZON_NTP_POOL. Antes de automatizar um override, leia o script da sua AMI em vez de confiar no README.

Reproduzi isso num container amazonlinux:2023 com chrony 4.3. Como o chrony-config.service não roda dentro de container, o daemon subiu sem fonte nenhuma:

Reference ID    : 00000000 ()
Stratum         : 0
Leap status     : Not synchronised

É o mesmo estado que você veria numa imagem customizada em que esse serviço foi desabilitado. Leap status: Not synchronised com Stratum 0 significa que não existe fonte, não que a fonte está lenta.

No Amazon Linux 2 antigo, sem a configuração padrão, o fluxo é o clássico: sudo yum install chrony, a linha server 169.254.169.123 prefer iburst minpoll 4 maxpoll 4 no topo do /etc/chrony.conf e sudo systemctl restart chronyd. Repare no nome do serviço: chronyd no Amazon Linux, chrony no Ubuntu.

Não copie configurações cegamente entre Ubuntu e Amazon Linux. A validação com chronyc é mais confiável do que assumir que um systemctl restart resolveu tudo.

Como detectar drift antes de virar incidente

O comando date foi suficiente para levantar a suspeita no caso que vivi. Ele não substitui o Chrony, mas é uma ótima primeira checagem quando transações e jobs agendados parecem discordar.

Como estes comandos foram validados Em 18/10/2026, rodei a instalação e os comandos chronyc em containers ubuntu:24.04 (chrony 4.5) e amazonlinux:2023 (chrony 4.3), com o daemon em modo -x, que não mexe no relógio do host. O endpoint 169.254.169.123 só responde de dentro de uma EC2 e foi conferido contra a documentação da AWS na mesma data.

Valide no bootstrap Em autoscaling, deixe a instalação e a fonte NTP na imagem ou no bootstrap. Corrigir uma instância depois do incidente não protege a próxima que nascer.

Chrony não é só um substituto do NTP

Chrony implementa o protocolo NTP e oferece o cliente chronyc para observar fontes e estado do relógio. A configuração não deve ser tratada como um ritual de copiar comandos. Ela precisa refletir a fonte permitida, a conectividade e a criticidade do sistema.

Para máquinas transacionais e processadores de fila, minha regra é não esperar o sintoma virar investigação longa. Se horários não batem, começo com date, confirmo a fonte com chronyc sources -v e leio chronyc tracking. Isso corta boa parte da especulação.

Checklist operacional

• Chrony instalado e habilitado no boot.
• Fonte local da AWS (169.254.169.123) configurada apenas quando a máquina está na EC2.
• No Amazon Linux 2023, fonte conferida com chronyc sources, não com grep no /etc/chrony.conf.
• chronyc sources -v com uma fonte selecionada (^*).
• chronyc tracking com Leap status: Normal.
• Bootstrap de autoscaling reproduz a mesma configuração em todo nó.
• Alertas ou verificação periódica para offset inesperado.

Se o objetivo é automatizar uma verificação recorrente, veja como automatizar NTPdate com Shell Script. Para o caso de horário divergente afetando alarmes, o próximo passo é diagnosticar horário incorreto no Linux com CloudWatch.

Minha leitura: sincronização de horário não ganha atenção enquanto funciona. Quando para, ela faz sistemas saudáveis parecerem quebrados. Padronizar Chrony e validar a fonte no nascimento de cada instância custa pouco perto de investigar transação, fila e job com relógios contando histórias diferentes.