A documentação do chrony adverte
ATENÇÃO: Certos softwares serão seriamente afetados por tais saltos no horário do sistema. (Essa é a razão pela qual o chronyd usa o giro normalmente.) Documentação
Mas a documentação não dá exemplos. Quais são os exemplos de software que serão seriamente afetados? O sistema operacional ou algum processo em segundo plano está em risco?
Esta é uma questão um pouco aberta, mas deixe-me dar alguns exemplos:
Todo software que interage com hardware real. Se você tem uma torradeira que torra pão por 20 segundos e seu software é estúpido o suficiente para verificar o relógio de parede, você obterá pão branco ou queimado se corrigir o relógio enquanto espera pela torrada.
Praticamente todas as aplicações que controlam qualquer tipo de dispositivo industrial precisam de temporizações precisas, como, por exemplo, "abrir uma válvula por 5,3 segundos para obter a quantidade correta de fluido". Estar fora por mais de alguns milissegundos arruína seu produto.
Os aplicativos que posicionam qualquer coisa usando motores usarão motores de passo (que são lentos) ou interruptores finais para determinar quando parar. Mas, muitas vezes, você não tem uma chave em todas as posições importantes, então você fará alguma lógica "xm/s para A milissegundos, então ym/s para B milissegundos". Agora imagine que seu daemon NTP ajusta o tempo em um único milissegundo enquanto esta lógica está rodando...
Recentemente, fui mordido por um bug que remonta a 1999 e afeta a JVM e o Android Runtime: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4290274
Trabalho em um dispositivo que começa com a época de 1970 como hora atual e recebe a hora correta da rede um pouco mais tarde. Ocasionalmente, uma biblioteca de terceiros inicializava antes do tempo ser definido, causando um salto de tempo de 50 anos.
O resultado foi
scheduleAtFixedRateuma tentativa de alcançar ~ 50 anos de invocações ... que foram cerca de 27 milhões de invocações consecutivas sem atraso entre elas.Isso faria com que o GC enlouquecesse e geralmente atolasse o sistema até que fosse reiniciado
Tivemos um problema com um sistema embutido no veículo em que o relógio perdia tempo significativamente (devido a um problema elétrico). Mas as conexões sem fio eram intermitentes, então o tempo era corrigido apenas ocasionalmente. O resultado foi que, quando os veículos finalmente recebessem sem fio e, em seguida, uma atualização NTP, o relógio avançaria significativamente.
Vários sistemas estavam verificando o tempo "último válido" de certas coisas, como leituras de GPS, etc. De repente, todos eles eram "antigos", apesar de terem sido atualizados apenas 0,5 segundos antes.
Obviamente, uma reconfiguração poderia resolver o problema, mas era um problema.
O servidor Dovecot IMAP é afetado e (em versões mais antigas) ele (deliberadamente) se suicida se detectar que a hora do sistema saltou para trás. Na v2.0, pelo menos tenta remediar a situação.
Veja https://wiki.dovecot.org/TimeMovedBackwards
Já está em um comentário, mas pensei em postar como resposta também:
Os aplicativos que deveriam ter usado o relógio monotônico constante, mas não o fazem, também são afetados. Por exemplo, se o software verifica os keep-alives do cliente usando a hora atual, um salto no tempo pode expulsar todos os clientes.
Tenho visto regularmente que o software usa o relógio errado.
Muitos exemplos...