Vérification : l’état de chrony en une commande#

Pourquoi#

La batterie de non-régression (chapitre Vérification finale) valide un changement ; les graphes Munin (chapitre Munin) montrent les tendances sur la durée. Entre les deux, l’exploitation quotidienne a besoin d’un geste simple : une photographie complète de l’état du service, en une seule commande, lisible en quelques secondes.

chronyc sait enchaîner plusieurs rapports en une seule invocation (option -m), et quatre d’entre eux suffisent à couvrir tout le service : la discipline de l’horloge (tracking), la charge servie (serverstats), l’état des sources (sources -v) et leurs statistiques (sourcestats -v).

Comment#

chronyc -m tracking serverstats 'sources -v' 'sourcestats -v'

-m traite chaque argument comme une commande distincte ; les guillemets protègent celles qui embarquent une option ('sources -v').

Sortie réelle de ce serveur :

Reference ID    : 50505330 (PPS0)
Stratum         : 1
Ref time (UTC)  : Sun Jul 19 23:58:28 2026
System time     : 0.000000117 seconds fast of NTP time
Last offset     : +0.000000430 seconds
RMS offset      : 0.000000751 seconds
Frequency       : 0.015 ppm fast
Residual freq   : +0.016 ppm
Skew            : 0.151 ppm
Root delay      : 0.000000001 seconds
Root dispersion : 0.000005789 seconds
Update interval : 4.0 seconds
Leap status     : Normal
NTP packets received       : 27085049
NTP packets dropped        : 1954441
Command packets received   : 1185
Command packets dropped    : 0
Client log records dropped : 1731901
NTS-KE connections accepted: 70
NTS-KE connections dropped : 0
Authenticated NTP packets  : 314
Interleaved NTP packets    : 443
NTP timestamps held        : 1744
NTP timestamp span         : 16025
NTP daemon RX timestamps   : 0
NTP daemon TX timestamps   : 25129144
NTP kernel RX timestamps   : 3493864
NTP kernel TX timestamps   : 59
NTP hardware RX timestamps : 21635723
NTP hardware TX timestamps : 384

  .-- Source mode  '^' = server, '=' = peer, '#' = local clock.
 / .- Source state '*' = current best, '+' = combined, '-' = not combined,
| /             'x' = may be in error, '~' = too variable, '?' = unusable.
||                                                 .- xxxx [ yyyy ] +/- zzzz
||      Reachability register (octal) -.           |  xxxx = adjusted offset,
||      Log2(Polling interval) --.      |          |  yyyy = measured offset,
||                                \     |          |  zzzz = estimated error.
||                                 |    |           \
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
#* PPS0                          0   2   377     3   +148ns[ +553ns] +/-  696ns
#? GPS                           0   4   377    19  -2621us[-2621us] +/-  248us
^- 145.238.80.80                 1   9   377    81   -553us[ -552us] +/- 1605us
^- 2001:638:610:cecf::7b         1   9   377   135   -154us[ -153us] +/- 9813us
^- 139.143.5.30                  1   8   377   247   -535us[ -537us] +/- 5244us
^- 193.11.166.8                  1  10   377   531   -533us[ -535us] +/-   18ms
^- 129.6.15.25                   1   9   377   129   -529us[ -529us] +/-   44ms
^- 185.142.225.68                1  10   377  1101   +969us[ +923us] +/- 8319us
                             .- Number of sample points in measurement set.
                            /    .- Number of residual runs with same sign.
                           |    /    .- Length of measurement set (time).
                           |   |    /      .- Est. clock freq error (ppm).
                           |   |   |      /           .- Est. error in freq.
                           |   |   |     |           /         .- Est. offset.
                           |   |   |     |          |          |   On the -.
                           |   |   |     |          |          |   samples. \
                           |   |   |     |          |          |             |
Name/IP Address            NP  NR  Span  Frequency  Freq Skew  Offset  Std Dev
==============================================================================
PPS0                        6   3    22     +0.016      0.146    +40ns   277ns
GPS                        45  24   703     +1.883      1.989  -3307us   720us
145.238.80.80               8   5   60m     -0.019      0.141    -58us    75us
2001:638:610:cecf::7b       8   5   60m     -0.001      0.072   -164us    40us
139.143.5.30                7   4   30m     -0.013      0.139    -71us    34us
193.11.166.8                7   5  103m     +0.014      0.068   -483us    56us
129.6.15.25                12   7   68m     -0.028      0.051   -205us    48us
185.142.225.68              9   5  129m     +0.068      0.236  +1169us   344us

Bloc 1 : `tracking`, la discipline de l’horloge#

Champ	Lecture
`Reference ID (PPS0)`	la référence active est bien le PPS, pas une source de secours (chapitre Chrony)
`Stratum : 1`	le serveur annonce le niveau directement relié à une référence physique (chapitre Vue d’ensemble)
`Ref time`	l’instant de la dernière correction appliquée
`System time`	l’écart instantané entre l’horloge système et NTP (ici ≈ 0,1 µs)
`Last offset`	la dernière correction appliquée par la boucle
`RMS offset`	la métrique de précision : écart type de l’erreur, ici ≈ 0,75 µs, autour de la microseconde visée par ce projet
`Frequency`	la correction totale appliquée au quartz (0,015 ppm) ; une valeur aussi faible signifie que la compensation thermique absorbe déjà la part prévisible de la dérive (chapitre Chrony, `tempcomp`)
`Residual freq`	l’erreur de fréquence restante après toutes les corrections : proche de zéro sur un système sain
`Skew`	l’incertitude sur la fréquence estimée ; 0,151 ppm ici, la valeur retombe sous ~0,05 ppm en régime établi (elle remonte transitoirement après un redémarrage)
`Root delay` / `Root dispersion`	délai et incertitude cumulés vers la référence : quasi nuls, la référence est locale
`Update interval : 4.0 s`	le rythme des corrections, cohérent avec `poll 2` (2² = 4 s) du refclock PPS
`Leap status : Normal`	aucune seconde intercalaire pendante (chapitre Secondes intercalaires)

Bloc 2 : `serverstats`, le service rendu#

Champ	Lecture
`NTP packets received / dropped`	27 millions de requêtes servies, ~7 % rejetées : le `ratelimit` applicatif au travail (chapitre Chrony)
`Command packets`	les requêtes `chronyc` locales, aucune rejetée
`Client log records dropped`	la table de suivi des clients (`clientloglimit`) sature et recycle ses entrées : attendu sur un serveur public très sollicité
`NTS-KE connections accepted`	70 négociations NTS abouties (chapitre NTS) ; `dropped 0` : la limite `ntsratelimit` n’a pas eu à sévir
`Authenticated NTP packets`	les requêtes NTP effectivement protégées par NTS
`Interleaved NTP packets`, `timestamps held/span`	le support serveur du mode interleaved (`xleave`) : ces timestamps sont conservés (~1 700, sur ~4,5 h) pour les clients qui le demandent
`NTP daemon TX timestamps`	≈ 25 millions : les réponses servies sont horodatées en espace utilisateur, car l’horodatage matériel TX est bloqué par le bug du pilote macb (`kernel TX 59`, `hardware TX 384`, chapitre PHC)
`NTP kernel/hardware RX timestamps`	86 % des requêtes traitées reçoivent un timestamp matériel (21,6 M sur 25,1 M), le chiffre attendu avec le réglage `-R 1` de phc2sys (chapitre PHC) ; le reste retombe sur le kernel

Bloc 3 : `sources -v`, l’état des sources#

La grille de lecture détaillée (légende, symboles #*, #?, ^-, Reach octal) est au chapitre Chrony. Les trois vérifications de ce bloc : le PPS est sélectionné (#*, ±696 ns d’incertitude estimée), le GPS en #? avec un offset de quelques millisecondes est normal (rôle de désambiguïsation, noselect), et les six sources réseau ont toutes Reach 377 (8 réponses sur 8).

Bloc 4 : `sourcestats -v`, les statistiques par source#

Colonne	Signification
`NP`	nombre de points de mesure retenus dans la fenêtre statistique
`NR`	nombre de suites de résidus de même signe : très inférieur à `NP/2`, il signale des résidus corrélés (régression encore en cours de convergence)
`Span`	durée couverte par la fenêtre (`60m` = 60 minutes)
`Frequency` / `Freq Skew`	dérive estimée vis-à-vis de cette source, et incertitude sur cette estimation (ppm)
`Offset`	écart estimé vis-à-vis de cette source
`Std Dev`	dispersion des mesures

Trois lectures sur l’exemple : le PPS montre une dispersion de quelques centaines de nanosecondes sur sa fenêtre courte ; le GPS est bruité (dispersion sub-milliseconde) sans aucune conséquence (noselect) ; les sources réseau s’étalent de quelques dizaines à quelques centaines de µs d’offset apparent, l’ordre de grandeur de l’asymétrie réseau, pas celui des horloges (chapitre Comparaison des performances).

La lecture en dix secondes#

Reference ID = PPS0 et #* sur la ligne PPS : la bonne source pilote.
RMS offset autour de la microseconde ou mieux.
Residual freq proche de zéro.
Reach 377 sur toutes les sources.
Sources réseau cohérentes entre elles à quelques centaines de µs près.
NTS-KE accepted qui progresse, dropped à zéro.

Erreurs à éviter#

Juger le serveur sur un instantané. Un seul relevé n’est ni une moyenne ni une tendance : Skew élevé après un redémarrage, source LastRx ancienne à Poll 10, offset réseau ponctuellement fort sont des états transitoires normaux. La durée se juge sur Munin (chapitre Munin), la conformité sur la batterie du chapitre Vérification finale.
S’alarmer du GPS en #? ou de son offset milliseconde. C’est le fonctionnement nominal : cette source ne sert qu’à étiqueter la seconde (noselect, chapitre Chrony).
Comparer l’offset des sources réseau à la précision locale. Les centaines de µs affichées mesurent surtout l’asymétrie des trajets (chapitre Comparaison des performances), pas l’horloge locale.
Confondre Frequency, Residual freq et Skew. Correction appliquée, erreur restante, incertitude d’estimation : trois grandeurs différentes. Une Frequency faible avec tempcomp actif est un signe de bonne santé, pas une anomalie.
Oublier le socket Unix sous service durci. Sans -h /run/chrony/chronyd.sock, chronyc peut échouer sans message clair (chapitre Chrony, pièges).

Vérifier#

Ce chapitre est la vérification : la commande unique ci-dessus, exécutée à chaque visite. Ses deux compléments : les graphes Munin pour la tendance (24 h minimum), acceptance.sh pour la non-régression après un changement (chapitre Vérification finale).

📚 Pour aller plus loin
La documentation de référence de chaque champ : chronyc, documentation officielle (sections tracking, serverstats, sources, sourcestats).
Chapitres liés : Chrony (configuration des sources et pièges), PHC (horodatage matériel), Comparaison des performances (lecture critique des offsets réseau).