Um certificado que se recusa a se validar, logs desorganizados ou uma tarefa acionada uma hora muito cedo levam rapidamente a acusar o aplicativo. Comece por ler o relógio da máquina. Em uma VM ou servidor systemd, timedatectl mostra o fuso horário, o serviço NTP e o estado de sincronização antes de qualquer correção.
O objetivo é separar três casos: o momento UTC está errado, o fuso exibe uma hora local errada ou a sincronização de rede não está mais funcionando. Cada caso requer uma ação diferente.
Ler a hora, o fuso e o estado NTP
Primeiro, anote a hora local, o UTC e o estado gerenciado pelo systemd. Faça esse controle a partir de uma sessão que pode permanecer aberta se a hora ou o fuso precisarem ser modificados.
date -Is
date -u -Is
timedatectl statusA saída exibe especialmente Hora local, Hora universal, Hora RTC, Fuso horário, Relógio do sistema sincronizado e Serviço NTP. Uma máquina configurada em UTC pode exibir uma hora local inesperada enquanto mantém o momento correto. Assim, compare date -u -Is com uma fonte de referência conhecida antes de acusar o fuso.
Em um script, evite analisar a exibição do status. Solicite as propriedades úteis:
timedatectl show -p Timezone -p LocalRTC -p NTP -p NTPSynchronizedAlterar o fuso sem mover o relógio
Se o UTC estiver consistente, mas a hora local não, verifique primeiro se o fuso esperado existe:
timedatectl list-timezones | grep -Fx 'Europe/Paris'Em seguida, aplique o fuso, e re leia seu valor e a hora local:
sudo timedatectl set-timezone Europe/Paris
timedatectl show -p Timezone --value
date -IsEste comando muda a apresentação do momento UTC, mas não ajusta o relógio. Verifique os timers e as janelas de manutenção após a mudança. Um cron como 15 2 * * * segue a hora local do serviço, enquanto um timer systemd pode declarar seu próprio fuso.
systemctl list-timers --allO guia sobre timers systemd e sua diferença para cron ajuda a interpretar essa lista. Uma mudança de fuso não justifica um reinício de um servidor remoto.
Ativar NTP com um único cliente de sincronização
Antes de usar timedatectl set-ntp true, identifique o cliente já instalado. Dependendo da distribuição, o relógio pode ser gerenciado por systemd-timesyncd, Chrony ou ntpd.
systemctl list-unit-files | grep -E '^(systemd-timesyncd|chrony|chronyd|ntp).service'
systemctl is-active systemd-timesyncd
systemctl is-active chrony
systemctl is-active chronydUm serviço inativo não significa que você deva iniciar todos os outros. Mantenha apenas um cliente NTP. Em uma máquina que usa systemd-timesyncd, ative a sincronização e verifique seu resultado:
sudo timedatectl set-ntp true
timedatectl show -p NTPSynchronized --value
timedatectl show-timesync --all
journalctl -u systemd-timesyncd -b --no-pagerA propriedade NTPSynchronized=yes confirma que o systemd considera o relógio sincronizado. show-timesync também fornece o servidor escolhido e os parâmetros conhecidos de timesyncd. Se Chrony já gerencia o relógio, use suas ferramentas em vez de reativar o timesyncd. O artigo sobre Chrony no Linux cobre esse caso.
Evitar uma correção manual em um servidor
Não execute timedatectl set-time só porque um log parece atrasado. Um salto manual pode perturbar certificados, Kerberos, expirações de sessão, bloqueios de banco de dados e tarefas agendadas.
Verifique também como o Linux interpreta o relógio de hardware:
timedatectl status
sudo hwclock --showO Linux geralmente mantém o relógio de hardware em UTC. Se RTC in local TZ tem o valor yes, verifique a política da máquina antes de mudar para UTC, especialmente com um dual boot Windows. Essa configuração pode mover a hora na próxima inicialização.
Após uma correção, re leia timedatectl status, as próximas execuções e os últimos dez minutos do log do serviço correspondente. Se o momento, NTP e os novos eventos coincidirem, o aplicativo muitas vezes não pede nenhuma reinicialização.
A documentação do timedatectl do systemd detalha o comportamento do set-ntp e as propriedades disponíveis conforme a versão instalada.