Início / unix / Perguntas / 791197
Accepted
Seamus
Asked: 2025-02-18 13:53:11 +0800 CST

Como confirmar se o kernel está (ou não) atualizando o hwclock/RTC

  • 772

Esta pergunta é uma continuação desta resposta . Em geral, meu objetivo é saber se meu sistema (Debian/Raspberry Pi 5 'bookworm') está atualizando meu relógio RTC/hardware a partir do horário do sistema. Observe que o RPi 5 (diferentemente de seus ancestrais Pi) tem um relógio RTC/hardware embutido .

Aqui está o que consegui determinar até agora:

1. Sinto que estabeleci que o relógio do sistema está sendo atualizado a partir do hwclock:
$ dmesg | grep "system clock" 

[    1.588793] rpi-rtc soc:rpi_rtc: setting system clock to 2025-02-18T04:59:13 UTC (1739854753)

Depois de alguma busca dmesg, no entanto, não consegui encontrar nenhuma indicação de que o hwclock esteja sendo atualizado a partir do horário do sistema. No entanto, encontrei uma referência a um fake-hardwarerelógio (o que parece estranho ). :

[    4.037230] systemd[1]: Starting fake-hwclock.service - Restore / save the current clock...
2. O kernel está aparentemente configurado para fazer atualizações de relógio em "ambas as direções":
$ cat /boot/config-$(uname -r) | grep -i HCTOSYS
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"  

$ cat /boot/config-$(uname -r) | grep -i SYSTOHC
CONFIG_RTC_SYSTOHC=y
CONFIG_RTC_SYSTOHC_DEVICE="rtc0"

Ocorreu-me que o kernel pode estar executando a sincronização SYSTOHC somente durante o desligamento, e talvez não esteja sendo capturado por dmesg... mas isso é um WAG.

Alguém pode explicar como confirmar se o kernel está (ou não) atualizando o hwclock/RTC?

linux-kernel

2 respostas

  1. Bem, se essa variável de configuração estiver definida e o kernel não tiver sido alterado, é exatamente como você disse: o RTC é atualizado pelo relógio do sistema a cada 11 minutos (suspensões e outros eventos não obstante).

    Você é, é claro, livre para desconfiar do seu compilador de kernel, ou se perguntar se a verificação ntp_synced()no código vinculado acima é verdadeira. With sudo perf stat -e rtc:rtc_set_timecontaria todas as vezes que a função de configuração de tempo RTC do kernel foi chamada. Deixe-a rodar por > 11 minutos, então ctrlc: se a contagem for > 0, seu RTC foi definido.

    Tenho que perguntar isto: de onde você tirou o comando para rastrear... o rtc:rtc_set_time?

    Li o código-fonte do Linux no primeiro link da minha resposta. Lá, duas coisas foram tentadas para definir o RTC, a coisa que eles chamavam de "legado" e a coisa mais nova.

    Verifiquei rapidamente se o legado não estava implementado no arm, então seu kernel estava usando a maneira mais nova, update_rtcentão li o código-fonte dessa função.

    Ele chama rtc_set_time, e que contém a linha

        trace_rtc_set_time(rtc_tm_to_time64(tm), err);

    Isso sugeriu que havia um ponto de rastreamento " rtc_set_time". Então, fui e procurei por um:

    sudo perf list | grep rtc_set_time

    e encontrei!

    • 2
  2. Best Answer

    Alguém pode explicar como confirmar se o kernel está (ou não) atualizando o hwclock/RTC?

    Instale a ferramenta adjtimex , execute adjtimex -pe anote o valor "status". A ferramenta é antiga e um pouco rudimentar e nem mesmo decodifica os sinalizadores de status para texto, então você terá que usar uma calculadora ou Python ou algum outro REPL para verificar se ele inclui o valor 64 (STA_UNSYNC). Se o sinalizador estiver ausente, o relógio será mantido em sincronia; se estiver presente, o relógio não será sincronizado e as atualizações RTC serão desabilitadas.

    $ adjtimex -p
 status: 24577

$ echo $[24577 & 64]
0

$ python
>>> 24577 & 64
0

    (Infelizmente, não é isso que o timedatectlitem "Relógio do sistema sincronizado:" relata, embora eu estivesse prestes a sugerir isso. Ele ignora deliberadamente a indicação STA_UNSYNC e considera apenas o maxerror.)

    Geralmente, STA_UNSYNC é definido por padrão e o RTC permanece intocado pelo kernel, a menos que você tenha um daemon NTP em execução (timesyncd, chrony, ntpd) que ajusta o relógio do sistema e limpa o sinalizador para habilitar atualizações de RTC.

    Observe que o popular daemon NTP chrony nem sempre depende do kernel para atualizar o RTC; sua configuração padrão costumava ser que o próprio daemon chrony faria os ajustes de hwclock, deixando o STA_UNSYNC definido (ou seja, atualizações do kernel desabilitadas).

    Abordagem experimental alternativa: Use hwclockpara definir o RTC para um horário obviamente errado , então espere aprox. 11 minutos (o intervalo de atualização usual do kernel), então leia o valor RTC novamente. Se agora estiver correto, então algo definitivamente o atualizou.

    Ocorreu-me que o kernel pode estar executando a sincronização SYSTOHC somente durante o desligamento e talvez não esteja sendo capturado pelo dmesg...

    Se isso for feito apenas no desligamento, então não será feito pelo kernel – isso faz parte dos scripts de inicialização/desligamento da sua distribuição.

    No entanto, encontrei uma referência a um relógio de hardware falso (o que parece estranho).

    Como você notou, versões anteriores do Pi não tinham um RTC real. Mas elas ainda precisavam armazenar o tempo aproximado do sistema em algum lugar, para que o sistema não inicializasse em 1970 toda vez. Assim, um arquivo no disco serve como um RTC que não faz tique-taque.

    (O Systemd de fato tem essa funcionalidade incorporada, mesmo sem o fake-hwclock.service.)

    • 1

relate perguntas