Artigo > Como ajustar o Localtime/Timezone no Linux

1812 Views

Pode parecer bobagem, mas manter o horário correto de um servidor Linux é algo muito sério. É tão sério que se o horário de um servidor estiver errado, dependendo do que esse servidor executa, você não pode simplesmente corrigir o horário e achar que está tudo bem, por que não estará. Por exemplo; se a hora do server estiver marcando 20hrs, e você corrige para 19hrs, um hipotético banco de dados desse server terá registros das 19 às 20 durante o intervalo de 2 horas. Viu? É tensinho.

Agora que vimos que o horário de um servidor pode ser algo muito polêmico, vamos ao que interessa: Como tratar data/hora de sistemas Linux.

Observe que neste artigo falo de ambientes de servidores, mas o artigo também se aplica para desktops Linux. A questão dos desktops é que você pode tratar a data/hora com alguns clicks do mouse, mas é isso, também se aplica à desktops.

O papel importante do Chronyd

Trata-se de um serviço das distribuições Linux que fica em execução no sistema para manter o horário sempre correto. O Chronyd é o daemon de serviço Chrony.

Antigamente usávemos o NTP, que também sincronizada horários do sistema. Porém o Chrony é muito mais rápido do que o NTP: O Chrony opera na casa dos 70 nanosegundos. Sabe o que isso representa? Um piscar de olhos leva 100 milissegundos. Isso são 1.000.000 de nanossegundos. O Chrony conseguiria trocar o horário do sistema 14.285 vezes em 1 piscar de olhos.

Ou seja, se o horário atrasar, mal terá tempo para ficar atrasado, pois o Chrony corrigirá quase que no mesmo instante em que o atraso ocorrer.

Para que ele funcione, são precisos alguns servidores de sincronismo de horário que no Chrony chamamos de Sources. Eles fornecem a hora exata de acordo com cada GMT.

Apresentações feitas, vamos ao how-to

Como o Chrony sincroniza horários?

O Chrony sabe qual deve ser sua data e hora com base no /etc/localtime. Este é um link simbólico ou symlink que aponta para um arquivo de timezone que, por sua vez, determina a data e hora. Os arquivos timezone são providos pelo pacote tzdata e são alocados no diretório /usr/share/zoneinfo.

Ou seja, se eu apontar meu /etc/localtime para o arquivo de timezone “/usr/share/zoneinfo/America/New_York”, estarei determinando que a data e hora do meu sistema será de Nova York.

Determinando a hora do sistema

O primeiro passo é saber se o nosso /etc/localtime está apontando para o timezone que precisamos. Então execute um ls -la para sabermos. Teremos uma saída como esta:

[root@wtf4ever ~] # #verificando o apontamento do localtime:
[root@wtf4ever ~] # ls -l /etc/localtime 
lrwxrwxrwx. 1 root root 38 Apr 21 10:41 /etc/localtime -> ../usr/share/zoneinfo/America/New_York

[root@wtf4ever ~] # #verificando a data/hora:
[root@wtf4ever ~] # date
Mon Apr 24 02:55:44 AM EDT 2023

Nova York está com GMT -4. Logo, tem uma hora a menos do que São Paulo que está em GMT -3. Ou seja, o sistema está 1 hora atrasado.

A correção consiste em ajustar o symlink do /etc/localtime para America/Sao_Paulo. Para isso, precisamos desfazer o symlink atual e recriá-lo apontando para o timezone que queremos:

Lembre-se: Tenha cuidado ao mudar horário em servidores de produção, pois alguns serviços herdarão o novo horário quando reiniciados. É o caso do Apache e do MySQL, por exemplo.

[root@wtf4ever ~] # #desfazendo o symlink:
[root@wtf4ever ~] # unlink /etc/localtime 

[root@wtf4ever ~] # #recriando o symlink apontando para o timezone desejado:
[root@wtf4ever ~] # ln -s /usr/share/zoneinfo/America/Sao_Paulo /etc/localtime

[root@wtf4ever ~] # #verificando se deu boas:
[root@wtf4ever ~] # ls -l /etc/localtime 
lrwxrwxrwx 1 root root 37 Apr 24 03:56 /etc/localtime -> /usr/share/zoneinfo/America/Sao_Paulo

[root@wtf4ever ~] # #verificando a data/hora após a mudança:
[root@wtf4ever ~] # date
Mon Apr 24 03:56:14 AM -03 2023

Repare que sequer precisei rodar algo para que o Chrony fizesse o sincronismo, pois ele está em execução. De agora em diante, neste sistema, o Chrony se encarregará de manter a data e hora atualizados.

Agora, se por algum motivo ocorrer de o Chrony não atualizar o horário, é sinal que algo de errado está ocorrendo. Algumas possibilidades para isso ocorrer:

1. O Chrony não está alcançando os Sources (NTP servers)
2. O Chrony não está em execução

Verificando comunicação com os Sources

Executando o comando chronyc -a sources fazemos um “ping” nos servidores que proveem data/hora para o Chrony. Devemos ter uma saída como essa:

[root@wtf4ever ~] # chronyc -a sources
MS Name/IP address         Stratum Poll Reach LastRx Last sample               
===============================================================================
^- sa-north-1.clearnet.pw        2   8   377   356   -900us[ -889us] +/-   27ms
^* brsao4-ntp-001.aaplimg.c>     1  10   377    26   +189us[ +200us] +/- 3292us
^- ntp-d.0x5e.se                 2   9   377   720  -1031us[-1020us] +/-  135ms
^- vps-7d02b399.vps.ovh.net      2  10   377   165    +23ms[  +23ms] +/-  152ms
^+ a.st1.ntp.br                  1  10   377  1000   -908us[ -897us] +/- 4892us
^+ gps.jd.ntp.br                 1  10   377    78   +253us[ +264us] +/- 3820us
^+ c.st1.ntp.br                  1  10   375   611  -3886us[-3875us] +/- 7533us
^- b.ntp.br                      2  10   377   728  -1098us[-1088us] +/-   48ms
^- c.ntp.br                      2  10   377   921   -994us[ -984us] +/-   23ms

Caso obtenha um resultado diferente deste, possívelmente há bloqueio de saída em um firewall ou alguma configuração de roteamento de rede impedindo a comunicação. Nesse caso cabe verificação.

Do contráro, caso tenha uma saída como essa, é provável que o Chrony esteja parado ou travado.

Verificando se o Chrony está no ar

Muito simples. Basta executar:

systemctl status chronyd

Você deve ter uma saída como esta:

[root@wtf4ever ~] # #verificando se o chronyd está no ar
[root@wtf4ever ~] # systemctl status chronyd
? chronyd.service - NTP client/server
     Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled; preset: enabled)
    Drop-In: /usr/lib/systemd/system/service.d
             ??10-timeout-abort.conf
     Active: active (running) since Mon 2023-04-24 02:41:40 -03; 1h 57min ago
       Docs: man:chronyd(8)
             man:chrony.conf(5)
    Process: 11501 ExecStart=/usr/sbin/chronyd $OPTIONS (code=exited, status=0/SUCCESS)
   Main PID: 11503 (chronyd)
      Tasks: 1 (limit: 9314)
     Memory: 1.1M
        CPU: 161ms
     CGroup: /system.slice/chronyd.service
             ??11503 /usr/sbin/chronyd -F 2

Repare na linha “Active”:

Active: active (running) since Mon 2023-04-24 02:41:40 -03; 1h 57min ago

O “running” aqui indica que ele está em execução. Qualquer coisa diferente disso é sinal de problema no serviço.

Agora, se consegue comunicação e o chronyd está rodando, ai ai ai, pode ser algo no source usado na configuração do Chrony.

Esse tipo de caso é bem pouco provável que ocorra, mas pode acontecer sob certas circunstâncias. Vale a pena, nesse caso, trocar o source na configuração do /etc/chronyd.conf. Abrindo o arquivo para edição, você verá uma linha começando com “pool” como neste exemplo:

# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (https://www.pool.ntp.org/join.html).
pool 2.fedora.pool.ntp.org iburst

Basta comentar as linhas e adicionar os novos sources.

Resumo

Bem, espero ter ajudado com essas observações e considerações. Não é salgo tão imples, com informei. Pleo contrário, pode ser bem complexo se consideremos regras de negócios e dinheiro. Todo cuidado é pouco.

Abraços e até a próxima.