Posso rispondere ad alcuni di questi punti, compreso il titolo.
[...] che correlano sempre con
systemd-timesyncd
aggiornare l'orologio di sistema. Con questo intendo dire che il primissimo messaggio syslog dopo un salto temporale è unTime has been changed
messaggio syslog:grep 'Time has been changed' /var/log/syslog Oct 2 23:53:33 hostname systemd[1]: Time has been changed
In realtà, questo messaggio non ti dice quale programma ha causato il salto temporale. È solo un sintomo del salto temporale.
Succede quando il kernel dice systemd
l'orologio è stato cambiato.[*] systemd
risponde scrivendo questo messaggio nel registro di sistema e quindi ricalcolando quando qualsiasi .timer
le unità dovranno essere attivate.
Il messaggio viene stampato dal programma systemd
, non da systemd-timesyncd
.
Più specificamente, il prefisso del messaggio "systemd[1]:" significa che proviene dall'ID processo 1. PID 1 è lo speciale processo "init". Il progetto systemd lo chiama anche "gestore di sistema", per distinguerlo dalle istanze di systemd
che gestiscono i servizi per gli utenti.
Il programma chiamato systemd
non cambia l'orologio dopo che il sistema ha terminato l'avvio.
Nell'attuale albero dei sorgenti di systemd a cui ti colleghi, l'unico programma che legge anche l'RTC / hardware clock / hwclock è timedated
, e solo se lo interroghi utilizzando timedatectl
.
Per quanto ricordo, le versioni precedenti di systemd
programma legge l'hwclock una volta all'avvio, prima di eseguire qualsiasi altro programma, e imposta l'orologio di sistema di conseguenza. Nell'ultima versione, systemd
non lo fa. C'è solo qualche trucco per dire al kernel quale fuso orario viene utilizzato per l'orologio hardware. (Evitando di innescare qualcosa di molto specifico chiamato "distorsione temporale").
In altre parole, l'attuale systemd
sembra presumere implicitamente che qualcos'altro inizializzi l'orologio di sistema. Nella maggior parte dei casi, questo sarà il kernel.
Cerca l'opzione di compilazione del kernel "Imposta l'ora di sistema da RTC all'avvio e riprendi" - CONFIG_RTC_HCTOSYS
.
Per una comprensione completa, nota che esiste anche un'opzione "Imposta l'ora RTC in base alla sincronizzazione NTP" - CONFIG_RTC_SYSTOHC
.
[*] Le modifiche all'orologio di sistema vengono rilevate utilizzando una funzionalità specifica di Linux. Vedi TFD_TIMER_CANCEL_ON_SET
.
Grazie mille a sourcejedi per questa risposta. Questo mi ha davvero portato a trovare la risposta giusta.
Risposta alla domanda
In che modo Linux utilizza un orologio in tempo reale per mantenere l'orologio di sistema?
Lo fa solo una volta, durante l'avvio. Non interrogherà nuovamente l'RTC fino al prossimo riavvio. Questo è configurabile, ma lo farà per impostazione predefinita sulla maggior parte delle build del kernel.
Voglio sapere se un errore con l'orologio in tempo reale si presenterebbe solo nell'orologio di sistema quando un agente timesync (ntpd o systemd-timesyncd) si aggiorna.
A meno che il sistema non venga riavviato, è improbabile che l'ora nell'RTC entri nell'orologio di sistema. Alcuni agenti come ntpd
può essere configurato per utilizzare un RTC come sorgente dell'ora, ma di solito non è abilitato per impostazione predefinita. È sconsigliabile abilitarlo a meno che tu non sappia che l'RTC è un'ottima fonte di tempo.
Esiste un collegamento diretto tra l'orologio di sistema?
Sembra che l'ora sia copiata al contrario. L'RTC viene periodicamente aggiornato con l'ora di sistema. Secondo la risposta di sourcejedi, questo viene fatto dal kernel se CONFIG_RTC_HCTOSYS è impostato.
Questo può essere testato:
-
Imposta l'RTC
# hwclock --set --date='18:28'
-
Quindi controlla l'ora RTC ogni pochi minuti con:
# hwclock
Il risultato sarà che l'ora di sistema non cambierà affatto e l'RTC ritornerà infine all'ora di sistema.
La causa del salto temporale sul BBB
Come ha sottolineato sourcejedi, i messaggi non venivano attivati da systemd-timesyncd
. Sono stati attivati da connman
. Le prove erano (dovrebbero essere) un messaggio di registro spurio in /var/log/syslog
:
Oct 3 00:10:37 hostname connmand[1040]: ntp: adjust (jump): -27302612.028018 sec
...
Nov 21 00:07:05 hostname systemd[1]: Time has been changed
prima della versione 1.37, connman è hardcoded per interrogare in modo promiscuo il gateway predefinito per l'ora. Non è necessario che sia configurato DHCP per eseguire questa operazione e se il client NTP di connman è abilitato (è per impostazione predefinita) quindi lo farà indipendentemente da qualsiasi altra configurazione.
Nel nostro caso alcuni router domestici stavano effettivamente rispondendo a queste richieste NTP, ma i risultati erano altamente inaffidabili. In particolare quando il router è stato riavviato, ha continuato a distribuire l'ora senza conoscere l'ora esatta .
Ad esempio, sappiamo che almeno una versione di BT Home Hub 5, al riavvio, passerà per impostazione predefinita al 21 novembre 2018 e fornirà questa data tramite NTP. Il suo client NTP risolverà quindi il problema, ma c'è una finestra in cui verrà distribuito il 21 novembre 2018.
Cioè, questo problema è stato causato in ultima analisi dal fatto che i nostri clienti hanno riavviato il loro router e Connman ha semplicemente accettato questa volta.
Esprimerò qui la mia frustrazione, sembra che la belligeranza di alcuni abbia lasciato questa "caratteristica" in Connman per troppo tempo. È stato segnalato come un problema già nel 2015. Ed è una "caratteristica" davvero ben nascosta. Non ci sono timeserver configurati e nessun messaggio di registro per spiegare cosa sta facendo connman o documentazione sul perché. Se i tuoi banchi di prova non hanno un server NTP sul gateway predefinito, non lo vedrai mai nei test.
Come risolvere
Stiamo esaminando due opzioni che sembrano funzionare entrambe:
-
Rimuovi completamente Connman. Sembra che la rete funzioni bene senza di essa; non abbiamo ancora trovato il motivo per cui è lì in primo luogo.
apt-get remove connman
-
Disabilita NTP in connman modificando
/var/lib/connman
includere:[global] TimeUpdates=manual