Estou executando uma instalação razoavelmente nova de 17.10 em um novo sistema (totalmente corrigido e não virtualizado) e observei que o tempo de inicialização listado na entrada /proc/stat 'co_de%' continuava mudando. Isso quebrou alguns scripts que usaram essas informações para calcular a hora do relógio na parede em que certos processos foram iniciados.
Com alguma depuração, descobri que btime é calculado como btime e a now() - uptime derivada deveu-se ao fato de que o relógio do sistema estava incrementando em uma taxa diferente da que o relógio de tempo de atividade estava!
Eu assumi que isso se devia a algum tipo de relógio aplicado ao relógio do sistema por btime (ou seja, a systemd-timesyncd.service de substituição), então desabilitei ntpd e reiniciei, como um teste. Com certeza, agora o contador de tempo de atividade e o clock do sistema pisam na mesma taxa. (Eu também instalei timesyncd para verificar os parâmetros do kernel para verificar se nenhum relógio girou permanece: não há% de adjtimex aplicado e o valor frequency é 10000, como deveria ser.)
Sem tick , no entanto, está claro que o relógio do sistema está muito fora de sintonia. O relógio perdeu cerca de 5 minutos ao longo de 135 minutos (~ -37000 ppm), o que é similar ao que eu usei com timesyncd ao longo de cerca de 20 minutos para estimar manualmente o desvio do clock do sistema ppm). (E, na verdade, apenas para verificar, usando um cronômetro, descobri que adjtimex -l -w também está incrementando na taxa errada; ~ -41000 ppm. Então, isso é consistente.)
O relógio CMOS também está um pouco desligado (ele ganhou 30 segundos nos 135 minutos), mas, no meu entender, isso não deve afetar o relógio do sistema, exceto no momento da inicialização. Não há arquivo /proc/uptime que eu possa encontrar pelo qual a taxa de clock do sistema seria alterada na inicialização - e de qualquer forma, como acima, /etc/adjtime informa que não houve falsificação de clock-tick. Então não consigo imaginar como o relógio CMOS pode estar causando o problema que vejo no relógio do sistema.
No entanto, vou mudar a bateria do CMOS, pois alguns relatórios sugeriram que isso pode corrigir milagrosamente os problemas do relógio do sistema. (Apesar de não haver nenhum mecanismo óbvio pelo qual isso possa acontecer.)
Mas existe alguma outra explicação para o fato de o relógio do sistema estar tão errado? E há alguma solução para o fato de que os temporizadores do sistema estão desativados por uma quantidade tão grande? Claramente, apenas executar adjtimex não resolve o problema, porque o excesso de relógio que ele produz é problemático (como acima).
Eu poderia usar timesyncd para alterar os parâmetros do kernel diretamente (o que deve manter os contadores de tempo de atividade e de sistema sincronizados pelo menos), mas isso realmente significa endereçar erros de relógio no intervalo de + - 500 ppm. O que estou vendo é 3 ordens de grandeza maior, e me pergunto se isso indica algum problema mais significativo.
Para o registro, uma instalação 17.10 que eu tenho em uma máquina muito semelhante não tem esse problema.
Atualização: mudar a bateria do CMOS não fez nada (como suspeito). Veja abaixo a resolução final do problema.