Probleme ntp sur debian buster

kiye · Décembre 3, 2021, 4:21pm

Bonjour,

Je me suis aperçu d’un problème de synchonisation de la date par ntpd sur ma debian buster. J’ai ntpd qui est installé.

# systemctl status ntp
● ntp.service - Network Time Service
   Loaded: loaded (/lib/systemd/system/ntp.service; enabled; vendor preset: enabled)
   Active: active (running) since Sat 2019-06-22 21:45:51 UTC; 2 years 5 months ago
     Docs: man:ntpd(8)
  Process: 801 ExecStart=/usr/lib/ntp/ntp-systemd-wrapper (code=exited, status=0/SUCCESS)
 Main PID: 813 (ntpd)
   Memory: 1.4M
   CGroup: /system.slice/ntp.service
           └─813 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 108:114

# timedatectl
               Local time: Thu 2021-12-02 18:15:07 UTC
           Universal time: Thu 2021-12-02 18:15:07 UTC
                 RTC time: Thu 2021-12-02 18:15:08
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: inactive
          RTC in local TZ: no

 # ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 0.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.002
 1.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.002
 2.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.002
 3.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.002
#78.251.129.10   193.52.184.106   2 u   43   64  177   13.011   -3.182   0.693
#ntp-1.arkena.ne 145.238.203.14   2 u   43   64  175   15.121   -2.888   0.685
-aru11.polo-unia 193.204.114.233  2 u   54   64   37   37.215   -1.245   0.185
-cp01.webhd.nl   195.154.174.209  3 u   49   64   77    8.531    0.892   1.065
+ip139.ip-5-196- 145.238.203.14   2 u   10   64  377    8.666    0.270   0.530
-lul1.ntp.netnod .PPS.            1 u   13   64   77   48.454   -0.261   0.246
-ntp10.kashra-se 90.187.148.77    2 u   16   64  377    9.099    0.189   1.121
-dalaran.sceen.n 145.238.203.14   2 u   40   64  177    8.543   -0.027   0.588
#backup.kabelnet 195.238.74.240   3 u  381   64  140   23.494   -0.789   0.646
-fluffykins.posi 85.199.214.98    2 u   43   64  177   12.293   -0.683   1.263
#ns1.pulsation.f 84.239.67.14     2 u   14   64  177    8.814    0.188   0.336
*85.199.214.98   .GPS.            1 u   21   64  177   13.271    0.748   0.122
-ntp2.torix.ca   .PTP0.           1 u   13   64  377   85.850    0.621   0.481
+leeto.nicolbola 145.238.203.14   2 u   12   64  377    5.700    0.682   0.545

Pour vérifier que la synchro marchait bien, j’ai forcé une date erroné pour vérifier que le système allait se remettre à la bonne date tout seul:

# timedatectl set-time "2019-06-22 13:41:00"

et la surprise, quand j’interroge la date du système quelques secondes apres, ce dernier ets toujours à la mauvaise date

# date
Sat 22 Jun 2019 01:41:07 PM UTC

alors que ntpd tourne toujours:

# systemctl status ntp
● ntp.service - Network Time Service
   Loaded: loaded (/lib/systemd/system/ntp.service; enabled; vendor preset: enabled)
   Active: active (running) since Sat 2019-06-22 21:45:51 UTC; 8h left
     Docs: man:ntpd(8)
  Process: 801 ExecStart=/usr/lib/ntp/ntp-systemd-wrapper (code=exited, status=0/SUCCESS)
 Main PID: 813 (ntpd)
   Memory: 1.4M
   CGroup: /system.slice/ntp.service
           └─813 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 108:114

Dec 02 18:08:05 b-0094 ntpd[813]: Listen normally on 3 tun0 192.168.160.148:123
Dec 02 18:08:05 b-0094 ntpd[813]: new interface(s) found: waking up resolver
Dec 02 18:17:35 b-0094 ntpd[813]: 213.109.127.82 local addr 10.168.2.160 -> <null>
Dec 02 18:17:38 b-0094 ntpd[813]: 95.81.173.8 local addr 10.168.2.160 -> <null>
Dec 02 18:17:40 b-0094 ntpd[813]: 78.251.129.10 local addr 10.168.2.160 -> <null>
Dec 02 18:18:10 b-0094 ntpd[813]: 80.74.64.1 local addr 10.168.2.160 -> <null>
Dec 02 18:18:38 b-0094 ntpd[813]: 95.110.248.206 local addr 10.168.2.160 -> <null>
Dec 02 18:19:17 b-0094 ntpd[813]: 194.58.206.20 local addr 10.168.2.160 -> <null>
Jun 22 13:41:13 b-0094 ntpd[813]: 151.80.211.8 local addr 10.168.2.160 -> <null>
Jun 22 13:41:22 b-0094 ntpd[813]: 164.132.166.29 local addr 10.168.2.160 -> <null>

# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 0.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.002
 1.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.002
 2.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.002
 3.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.002
+ip139.ip-5-196- 145.238.203.14   2 u    4   64  377    8.642    0.753 2920089
-ntp10.kashra-se 90.187.148.77    2 u    7   64  377    9.207    1.276 2920089
-fluffykins.posi 85.199.214.98    2 u   37   64  377   12.295    0.841 2920089
*85.199.214.98   .GPS.            1 u   18   64  377   13.271    0.748 2920089
-ntp2.torix.ca   .PTP0.           1 u    6   64  377   85.855    1.011 2920089
+leeto.nicolbola 145.238.203.14   2 u    2   64  377    5.702    1.175 2920089

Quelques minutes après, toujours la mauvaise date:

# date
Sat 22 Jun 2019 01:44:19 PM UTC

et le service ntp en rade

# systemctl status ntp
● ntp.service - Network Time Service
   Loaded: loaded (/lib/systemd/system/ntp.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Sat 2019-06-22 13:45:52 UTC; 4s ago
     Docs: man:ntpd(8)
  Process: 801 ExecStart=/usr/lib/ntp/ntp-systemd-wrapper (code=exited, status=0/SUCCESS)
 Main PID: 813 (code=exited, status=255/EXCEPTION)

Dec 02 18:18:38 b-0094 ntpd[813]: 95.110.248.206 local addr 10.168.2.160 -> <null>
Dec 02 18:19:17 b-0094 ntpd[813]: 194.58.206.20 local addr 10.168.2.160 -> <null>
Jun 22 13:41:13 b-0094 ntpd[813]: 151.80.211.8 local addr 10.168.2.160 -> <null>
Jun 22 13:41:22 b-0094 ntpd[813]: 164.132.166.29 local addr 10.168.2.160 -> <null>
Jun 22 13:45:39 b-0094 ntpd[813]: Soliciting pool server 91.224.149.41
Jun 22 13:45:40 b-0094 ntpd[813]: Soliciting pool server 95.81.173.155
Jun 22 13:45:49 b-0094 ntpd[813]: Soliciting pool server 156.106.214.48
Jun 22 13:45:49 b-0094 ntpd[813]: Soliciting pool server 2001:41d0:8:4d0d::1
Jun 22 13:45:52 b-0094 systemd[1]: ntp.service: Main process exited, code=exited, status=255/EXCEPTION
Jun 22 13:45:52 b-0094 systemd[1]: ntp.service: Failed with result 'exit-code'.

Si je relance le service ntp à la main, le système se remet à la « bonne » heure.

Que peut-il bien se passer, pourquoi ntpd se plante ainsi? c’est systématique
Je n’arrive pas à comprendre.
Si quelqu’un comprend merci de bien vouloir éclairer ma lanterne.

Cordialement,

Zargos · Décembre 3, 2021, 1:21pm

Bonjour,

NTPD est un serveur de temps. il est tilisé pour permettre à d’autres serveurs de se mettre à l’heure.
Avec une seule machine, vous n’en avez pas besoin.
timesyncd est largement suffisant.

AnonymousCoward · Décembre 3, 2021, 3:43pm

ntpd est d’abord et avant tout un client NTP. Il peut également fonctionner comme serveur NTP si on le configure ainsi.

timesyncd est également un client NTP. Je trouve absurde de dire qu’il est suffisant et qu’il n’y a pas à installer d’autre logiciel NTP.

Par exemple, j’ai vu récemment que l’utilisation de timesyncd était déconseillée pour une raison technique précise. Il me semble que c’était pour les serveurs Proxmox VE 7.

Ntpd est supposé corriger les erreurs de l’horloge temps réel (RTC) de manière progressive / douce. Il est possible qu’il crashe lorsque l’on impose au système un changement trop brutal de l’heure.

Eventuellement, il existe aussi chrony comme client / serveur NTP. Peut-être conviendra t’il mieux ?

–
AnonymousCoward

anon70622873 · Décembre 3, 2021, 3:46pm

Voir aussi ceci : Le serpent qui se mord la queue
Cela peut arriver si le décalage est trop important entre la date réelle et celle du système.

Zargos · Décembre 3, 2021, 6:37pm

Non, c’est avant tout un daemon.
NTP est conçu comme client/serveur, le client principal est ntpdate, ntpd peut être utilisé comme client, mais c’est juste parce qu’un serveur a besoin d’etre à l’heure pour fournir l’heure aux autres.
Chrony est conçu pour corriger le décalage de temps entre deux serveurs.
Utiliser ntpd c’est aussi ouvrir un port (le 123) inutilement, d’autant qu’il y a un certain nombre de vulnérabilité le concernant (un peu plus de 140 qui lui sont relié).

timesyncd est uniquement un client.

Almtesh · Décembre 4, 2021, 6:29am

Alors, déjà ntpd ne s’en rend pas compte en temps réel car les dérives d’horloge sont linéaires en général. Si tu as une horloge temps réel qui avance d’une seconde toutes les vingt milisecondes, ntpd peut corriger ça, mais si ton horloge se fait à se décaler comme tu l’as fait là, ça ne fonctionne pas du tout.

Oui, c’est probablement parce qu’il n’a pas compris ce qu’il s’est passé.
Si tu veux tester la mise à l’heure automatique, il faut éteindre ta machine, dérégler l’horloge dans le BIOS et redémarrer. Si tu n’as pas le temps de voir l’horloge a été déréglée dans ton système une fois lancé, c’est que le service a su gérer ça.

kiye · Décembre 6, 2021, 9:19am

Bonjour, merci pour vos réponses

Il me semblait que l’option -g de ntpd permettait de gérer une saute de temps importante en bypassant le ratrapage progressif

Il y a un mécanisme dans le kernel qui consiste à synchroniser la RTC toutes les 11 minutes sur l’heure système si celle-ci est elle-même synchronisée. Alors je ne sais pas comment le kernel sait que l’heure système est synchronisée mais je sais que ce mécanisme marche avec ntpd. Est-ce le cas avec timesyncd uniquement?

AnonymousCoward · Décembre 6, 2021, 2:22pm

Les dépôts Debian indiquent que le package ntpdate est obsolète / deprecated.

Ensuite, la page de man de ntpdate indique :

Donc non, ntpdate n’est pas le « client principal ».

–
AnonymousCoward

Zargos · Décembre 6, 2021, 5:09pm

Dans le fonctionnement de la synchronisation, il y a comparaison entre l’heure locale et l’heure du serveur de temps distant. de le cas d’un écart alors le client met à jour l’heure locale.

kiye · Décembre 6, 2021, 5:25pm

Oui j’avais bien compris le fonctionnement de la synchronisation de l’heure système mais ça ne répond pas à ma question sur la synchonisation de la RTC.

Zargos · Décembre 6, 2021, 5:35pm

je crois que tu peux utiliser:

defini l’heure RTC sur celle du système:

hwclock -w

défini l’heure RTC avec celle qui est précisée :

hwclock --set --date "$(date)"

kiye · Décembre 6, 2021, 5:38pm

Certes, mais il n’y a pas besoin de faire ça car ça se fait automatiquement par le kernel toutes les 11 minutes avec ntpd. ma question est : est que ça se fait aussi automatiquement avec timesyncd?

kiye · Décembre 7, 2021, 9:09am

La réponse est oui. J’ai testé, la RTC est bien synchronisée automatiquement avec timesyncd donc je pourrais tres bien me passer de ntpd (et donc du packet ntp)

Zargos · Décembre 7, 2021, 5:44pm

Non. Des que tu met ta machine hors tension si un ecart existait ton RTC conserve l’écart. et quand tu redemarres l’écart est toujours, ton système est ensuite synchronisé par ton RTC.

Le RTC c’est le matériel pas le logiciel.