J'utilise un Raspberry Pi 3 et j'ai besoin de mettre à jour l'heure via ntp après le redémarrage du système.
Il devrait être mis à jour via wifi avec dhcp. En général, cela fonctionne, mais la synchronisation nécessite env. une demi-heure et je ne comprends pas pourquoi.
Quand je veux démarrer le service ntp manuellement avec
>>sudo /etc/init.d/ntp restart
Il dit "ok", mais le système ne fait rien - la mauvaise heure est toujours sur le RTC.
Avez-vous une idée, quel pourrait être le problème ?
Une autre information est que le Pi fonctionne en mode lecture seule... mais s'il ne fonctionne pas sans accès en écriture, il ne sera pas mis à jour après une demi-heure, n'est-ce pas ?
Plus de détails :
Pour compléter mon problème voici le 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
...
Pour étoffer mon explication sur mon projet. Je veux utiliser le Pi comme serveur NTP. Le premier problème était que le RTC "s'enfuit" après un redémarrage ou lorsque le Pi s'éteint - surtout pendant une longue période. C'est pourquoi j'ai eu l'idée que le Pi devrait être un client NTP à la première fois pour définir le RTC et après cela, le Pi doit être un serveur NTP pour l'appareil, qui est connecté via ethernert avec le Pi. J'ai donc connecté le Pi via Wifi pour obtenir l'heure actuelle. Comme je l'ai déjà dit en général ça marche, mais ça prend trop de temps.
Ensuite j'ai voulu faire la synchronisation manuellement avec cette commande que j'ai posté avant. Mon idée était de faire cela en tant que cronjob, mais il y a le problème suivant :1. le Pi a ignoré la commande; 2. le cronjob est également ignoré ou supprimé après un redémarrage.
Mais je veux y aller étape par étape et le premier problème que je veux résoudre est de diminuer le temps de synchronisation.
J'espère que vous avez maintenant un meilleur aperçu de ma situation….
Avez-vous besoin de plus de détails ?
NOUVELLES INFORMATIONS :01.02.2018
D'accord, j'ai maintenant la solution que je veux, MAIS il y a un comportement que je ne comprends pas. Les configurations étaient correctes.
Cependant, j'utilise le WiFi intégré pour synchroniser l'heure du système via un serveur NTP, que j'ai configuré dans le ntp.conf. J'utilise l'Ethernet (LAN filaire) comme serveur NTP pour le périphérique filaire vers le RPi. Voici les paramètres IP :
WLAN (DHCP): 192.168.1.x
Ethernet (static): 192.168.10.10
J'ai mis les deux interfaces dans des réseaux différents, car sinon une seule connexion fonctionnerait - Mais pourquoi en fait ?
Et c'est le principal problème, pourquoi la synchronisation a pris si longtemps. Quand je commente la ligne avec l'horloge locale
Server 127.127.1.0
Ensuite, la synchronisation sur le réseau fonctionne immédiatement…
Pourquoi cela se produit-il ?
Réponse acceptée :
Le rpi n'a pas de RTC, et donc il démarre toujours le 1er janvier 1970 - le temps de synchroniser le serveur et le NTP lentement et progressivement est plus long ; donc, par défaut, NTP ne commence pas à fonctionner normalement tant que la différence entre NTP et le système n'est pas corrigée.
J'ajouterais à votre ntp.conf file comme première ligne (il doit s'agir de la première ligne) :
tinker panic 0
Cette configuration est conseillée pour les VM et appareils iOTs.
tinker panic – Spécifie le seuil de panique en secondes avec par défaut
1000 s. S'il est défini sur zéro, le contrôle de panique est désactivé et un décalage
d'horloge de n'importe quelle valeur sera accepté.
J'envisagerais également d'acheter un RTC, car il est bon marché, surtout si vous avez l'intention d'avoir des projets sans connexion Internet. voir hwclock ne peut pas ouvrir le fichier rtc