• [^] # Re: Logs ntpd => /etc/ntp.conf

    Posté par . En réponse au message NTP. Évalué à 1.

    Voici un extrait de mon ntpd.log...
    10 Feb 14:59:54 ntpd[714]: synchronisation lost
    10 Feb 14:59:54 ntpd[714]: system event 'event_clock_reset' (0x05) status 'leap_none, sync_unspec, 15 events, event_peer/strat_chg' (0xf4)
    10 Feb 14:59:54 ntpd[714]: system event 'event_peer/strat_chg' (0x04) status 'leap_none, sync_unspec, 15 events, event_clock_reset' (0xf5)
    10 Feb 15:00:07 ntpd[714]: peer 192.168.0.1 event 'event_reach' (0x84) status 'unreach, conf, 15 events, event_reach' (0x80f4)
    10 Feb 15:25:41 ntpd[714]: time reset -0.809834 s

    En fait, ça te dit quand il a perdu une synchro avec un serveur (défini dans ton /etc/ntp.conf), et les opérations qu'il peut faire avec le protocole NTP. Les system event sont peu utiles dans notre cas je pense...
    Ca dit aussi que mon ntpd a atteint 192.168.0.1 (qui est le serveur que j'ai défini dans mon ntp.conf), et qu'il a réinitialisé l'horloge qui comportait une erreur de moins d'une seconde... (j'ai pas trouvé grand chose en doc sur tout ça, mais je pense que ça doit être la bonne interprétation, non ?)

    En fait, je m'en sers surtout pour savoir si tout se passe bien. Ici, la perte de synchro de mon log n'est pas la fin du monde et ne reflète rien de significatif hormis quelques paquets perdus sur le réseau. Et comme le NTP fonctionne en mode UDP et non pas TCP, un paquet perdu est perdu (en TCP, il est redemandé et réexpédié en cas d'erreur), ce qui est logique, car on ne veut pas une synchro avec des paquets de données trop anciens...