Uso un Raspberry Pi 3 e devo aggiornare l'ora tramite ntp dopo aver riavviato il sistema.
Dovrebbe essere aggiornato via wifi con dhcp. In genere funziona, ma la sincronizzazione richiede ca. mezz'ora e non capisco perché.
Quando voglio avviare manualmente il servizio ntp con
>>sudo /etc/init.d/ntp restart
Dice "ok", ma il sistema non fa nulla:l'ora sbagliata è ancora sull'RTC.
Hai un'idea, quale potrebbe essere il problema?
Un'altra informazione è che il Pi viene eseguito in modalità di sola lettura... ma se non funziona senza accesso in scrittura non verrebbe aggiornato dopo mezz'ora, vero?
Maggiori dettagli:
Per completare il mio problema ecco ntp.conf:
# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help
Driftfile /var/lib/ntp/ntp.drift
Statistics loopstats peerstats clockstats
Filegen loopstats file loopstats type day enable
Filegen peerstats file peerstats type day enable
Filegen clockstats file clockstats type day enable
...
Server 0.de.pool.ntp.org iburst
Server 1.de.pool.ntp.org iburst
Server 2.de.pool.ntp.org iburst
Server 3.de.pool.ntp.org iburst
Server 127.127.1.0 #local clock
Fudge 127.127.1.0 stratum 10
...
Per ampliare la mia spiegazione sul mio progetto. Voglio usare il Pi come server NTP. Il primo problema era che l'RTC "scappa" dopo un riavvio o quando il Pi si spegne, specialmente per un tempo più lungo. Ecco perché ho avuto l'idea che il Pi dovrebbe essere un client NTP la prima volta per impostare l'RTC e successivamente il Pi deve essere un server NTP per il dispositivo, che è collegato tramite ethernert con il Pi. Quindi ho collegato il Pi tramite Wifi per ottenere l'ora corrente. Come ho già detto in genere funziona, ma ci vuole troppo tempo.
Poi ho voluto fare la sincronizzazione manualmente con questo comando che ho postato prima. La mia idea era di farlo come cronjob, ma c'è il problema successivo:1. il Pi ha ignorato il comando; 2. anche il cronjob viene ignorato o eliminato dopo un riavvio.
Ma voglio andare passo dopo passo e il primo problema che voglio risolvere è diminuire il tempo di sincronizzazione.
Spero che ora tu abbia una visione migliore della mia situazione….
Hai bisogno di maggiori dettagli?
NUOVE INFORMAZIONI:01.02.2018
Ok, quindi ora ho la soluzione che voglio, MA c'è un comportamento che non capisco. Le configurazioni erano corrette.
Tuttavia, utilizzo il WiFi integrato per sincronizzare l'ora del sistema tramite un server NTP, che ho configurato in ntp.conf. Uso Ethernet (LAN cablata) come server NTP per il dispositivo cablato sull'RPi. Qui le impostazioni IP:
WLAN (DHCP): 192.168.1.x
Ethernet (static): 192.168.10.10
Ho messo entrambe le interfacce in reti diverse, perché altrimenti funzionerebbe solo una connessione – Ma perché in realtà?
E questo è il problema principale, perché la sincronizzazione ha richiesto così tanto tempo. Quando commento la riga con l'orologio locale
Server 127.127.1.0
Quindi la sincronizzazione sulla rete funziona immediatamente...
Perché succede?
Risposta accettata:
L'rpi non ha un RTC, quindi si avvia sempre il 1 gennaio 1970:il tempo per sincronizzare il server e l'NTP in modo lento e incrementale è maggiore; quindi per impostazione predefinita NTP non inizia a funzionare normalmente fino a quando la differenza tra NTP e il sistema non viene corretta.
Aggiungerei al tuo ntp.conf file come prima riga (deve essere la prima riga):
tinker panic 0
Questa configurazione è consigliata per le macchine virtuali e dispositivi iOS.
tinker panic:specifica la soglia di panico in secondi con valore predefinito
1000 s. Se impostato a zero, il controllo di integrità panico viene disabilitato e verrà accettato un orologio
offset di qualsiasi valore.
Considererei anche l'acquisto di un RTC, in quanto è economico, soprattutto se intendi avere progetti senza connettività Internet. vedi hwclock non può aprire il file rtc