Dérive de l’horloge WSL2 : corriger le décalage temporel correctement

février 20, 2026 • février 20, 2026 • Lecture : 28 min • Views: 0

Cet article vous a aidé ?

Quand l’heure dans WSL2 dérive, rien ne tombe en panne discrètement. Les git fetch plantent avec des erreurs TLS. Les gestionnaires de paquets jurent que les métadonnées du dépôt viennent « du futur ». Les logs deviennent de la fiction. Et votre chronologie d’incident — déjà fragile — se transforme en danse interprétative.

Le pire : cela semble aléatoire. Vous fermez votre ordinateur, allez en réunion, revenez, et soudain votre environnement Linux croit que nous sommes mardi dernier. Réglons ça comme des adultes : mesurer d’abord, synchroniser la bonne horloge, et arrêter de colmater la dérive avec des rustines qui font hurler les outils de sécurité.

À quoi ressemble la dérive horaire WSL2 (et pourquoi vous devriez vous en soucier)

Le décalage d’horloge est l’un de ces problèmes « c’est juste quelques minutes » qui peuvent arrêter une chaîne entière. En exploitation, le temps est une promesse d’API : validité des certificats TLS, tickets Kerberos, expiration des tokens OAuth, corrélation des logs, spans de tracing distribué, invalidation de cache, reproductibilité de builds. Cassez le temps et vous cassez la confiance.

WSL2 ajoute une complication : c’est une VM Linux qui tourne sous les couches de virtualisation Hyper-V, avec son propre noyau. Ça veut dire que l’heure peut dériver au niveau du guest même quand Windows semble correct. Les transitions de veille/hibernation et la charge hôte peuvent aggraver le phénomène. Certains utilisateurs ont une instance WSL2 qui reprend avec une horloge obsolète ; d’autres voient une dérive périodique sous forte charge CPU ou lorsque le guest n’est pas planifié fréquemment.

Deux réalités rapides :

Le fait que l’horloge Windows soit correcte ne garantit pas que l’horloge WSL2 l’est.
Corriger l’heure en « définissant simplement la date » dans le guest est un pansement. Cela peut même créer des problèmes de sécurité en masquant l’absence d’une source de temps fiable.

Blague n°1 : La dérive temporelle, c’est comme la dette technique — vous l’ignorez jusqu’à ce qu’elle vous coûte pendant une panne.

Faits intéressants et contexte historique (vous serez plus malin à la fin)

NTP est plus ancien que beaucoup de systèmes modernes. Le Network Time Protocol existe depuis le début des années 80 et reste l’épine dorsale de la synchronisation horaire sur Internet.
La synchronisation d’horloge n’est pas juste « régler l’heure ». Les implémentations modernes disciplinent l’horloge progressivement pour éviter de casser les applications sensibles au temps.
Le temps virtualisé a toujours été étrange. Les premières plateformes VM peinaient avec les interruptions de timer et la planification, menant à des guests qui tournent « vite » ou « lentement » sous charge.
Monotone vs temps mur (wall-clock) compte. Linux fournit une horloge monotone pour mesurer des durées ; l’horloge murale peut sauter suite à des ajustements NTP ou des changements manuels.
Kerberos est notoirement intolérant au décalage. Les tolérances par défaut sont généralement de quelques minutes, pas d’heures. Au-delà, l’auth échoue d’une manière qui ressemble à des « identifiants cassés ».
TLS dépend du temps pour la sécurité basique. Les fenêtres de validité des certificats sont une vérification simple qui empêche la réutilisation et les abus. Une horloge incorrecte fait paraître les systèmes sécurisés comme brisés.
Les secondes intercalaires existent réellement. Elles sont rares, mais ont causé des incidents en production quand les systèmes ne sont pas d’accord sur leur traitement.
Windows et Linux diffèrent sur certaines hypothèses temporelles. Historiquement, les systèmes à double amorçage se disputaient sur le fait que l’horloge matérielle soit en heure locale ou en UTC ; cette bataille a appris à une génération à respecter la tenue du temps.

Comment WSL2 gère l’heure : les éléments en jeu

WSL2 est une VM légère avec un vrai noyau Linux. Il partage beaucoup avec les guests Hyper-V : timers virtuels, bus de virtualisation, et mécanismes d’intégration qui permettent au guest de coopérer avec l’hôte. Mais « léger » ne veut pas dire « immunisé contre les problèmes temporels de VM ». Cela signifie juste que les modes de défaillance sont plus furtifs.

Trois horloges à garder distinctes

Horloge murale de l’hôte Windows : ce que montre votre barre système ; généralement disciplinée via Windows Time service (w32time) ou le temps de domaine.
Horloge murale du guest WSL2 : ce que date affiche dans Linux ; peut dériver ou reprendre obsolète après une mise en veille.
Horloges monotones : utilisées pour mesurer des intervalles ; rarement le problème pour « TLS pas encore valide », mais pertinentes si vous observez des timeouts étranges ou des comportements de planification.

Pourquoi la mise en veille/hibernation est le méchant habituel

Quand un portable se met en veille, l’exécution CPU s’arrête. Au réveil, l’hôte met à jour son temps, mais la VM guest peut ne pas recevoir immédiatement un événement propre de synchronisation. Si la VM est mise en pause ou si sa tenue du temps repose sur une source virtuelle qui n’est pas corrigée rapidement, vous pouvez reprendre avec une horloge en retard. Plus vous mettez en veille, plus vous dérivez. Ce n’est pas mystique ; c’est la reprise d’état.

Pourquoi « lancer ntpdate » n’est pas le bon réflexe

Un saut horaire ponctuel peut casser des processus en cours. Bases de données, outils de build, et tout ce qui repose sur des horodatages peuvent mal fonctionner. L’approche correcte est d’activer un service horaire qui discipline l’horloge (corrections progressives), et de corriger la cause racine (resynchronisation au réveil, intégration WSL2, stabilité du temps hôte).

Idée paraphrasée (pas mot pour mot) de Richard Cook, chercheur en fiabilité : Les défaillances sont rarement ponctuelles ; elles résultent d’hypothèses normales qui s’alignent mal.

Guide de diagnostic rapide

Ceci est le flux « vous êtes en astreinte, tout échoue, et vous devez savoir ce qui ne va pas en cinq minutes ». Ne réfléchissez pas trop.

Première étape : confirmez la dérive et sa direction

Vérifiez l’heure Windows par rapport à une référence externe (ou au moins confirmez que Windows n’est pas complètement décalé).
Vérifiez l’heure dans WSL2 depuis la distribution.
Calculez le delta. Secondes ? Minutes ? Heures ? Cette échelle change la cause probable.

Deuxième étape : décidez si le guest peut atteindre une source de temps

Vérifiez la résolution DNS et l’accessibilité sortante UDP/123 (ou au moins l’accès HTTPS aux proxys temps d’entreprise si c’est votre environnement).
Vérifiez s’il existe un démon de temps en place et s’il tourne (systemd-timesyncd, chrony).

Troisième étape : isolez hôte vs guest vs politique réseau

Si Windows est erroné : corrigez d’abord l’heure Windows. Le guest qui se base sur un hôte cassé n’est pas un problème du guest.
Si Windows est correct mais WSL2 est incorrect : corrigez le mécanisme de synchronisation et le comportement de reprise du WSL2.
Si les deux sont parfois corrects et parfois non après mise en veille : implémentez une resynchronisation au réveil et vérifiez les mises à jour de version/du noyau WSL.
Si seul le réseau d’entreprise pose problème : il est probable que NTP soit bloqué et vous aurez besoin d’une source de temps autorisée ou d’une autre approche.

Tâches pratiques : commandes, sorties, décisions (12+)

Voici des vérifications pratiques à exécuter maintenant. Chaque tâche inclut : commande, ce que la sortie typique signifie, et la décision à prendre.

Task 1: Check WSL2 wall clock immediately

cr0x@server:~$ date -Is
2026-02-05T14:22:09+00:00

Signification : Horloge murale au format ISO-8601 dans WSL2. Comparez-la à Windows ou à une référence fiable.

Décision : Si elle est décalée de plus d’environ 2 minutes, traitez-le comme un vrai problème. Si elle est décalée de plusieurs heures, suspectez une reprise après mise en veille/hibernation ou des changements manuels.

Task 2: Check time zone and whether it’s a “timezone confusion” not drift

cr0x@server:~$ timedatectl
               Local time: Thu 2026-02-05 14:22:12 UTC
           Universal time: Thu 2026-02-05 14:22:12 UTC
                 RTC time: Thu 2026-02-05 14:22:12
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: no
              NTP service: inactive
          RTC in local TZ: no

Signification : Si « Local time » correspond aux attentes mais que le « Time zone » est incorrect, vous pourriez voir une confusion d’offset. Si « System clock synchronized » est no et NTP est inactive, le guest n’est pas discipliné.

Décision : Si NTP est inactif, activez un service de temps (systemd-timesyncd ou chrony). Si le fuseau horaire est incorrect, corrigez cela séparément — ne chassez pas une « dérive » qui est en réalité un décalage de fuseau horaire.

Task 3: Confirm systemd is actually running (WSL2 varies by config)

cr0x@server:~$ ps -p 1 -o comm=
systemd

Signification : Si PID 1 est systemd, vous pouvez utiliser les services systemd normalement. Si c’est autre chose (comme init ou bash), vous aurez besoin d’une autre approche (ou d’activer systemd dans WSL).

Décision : Si systemd n’est pas PID 1, décidez si vous allez activer systemd (recommandé pour une expérience Linux complète) ou exécuter chrony manuellement.

Task 4: If systemd exists, check timesync service status

cr0x@server:~$ systemctl status systemd-timesyncd --no-pager
● systemd-timesyncd.service - Network Time Synchronization
     Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled)
     Active: active (running) since Thu 2026-02-05 14:10:03 UTC; 12min ago
       Docs: man:systemd-timesyncd.service(8)
   Main PID: 319 (systemd-timesyn)
     Status: "Synchronized to time server 10.0.0.53:123 (ntp.corp)"

Signification : « Synchronized » est ce que vous voulez. Si cela indique « No network connectivity » ou « Timed out », votre chemin réseau vers NTP est bloqué ou mal configuré.

Décision : Si le service est actif et synchronisé, la dérive peut être liée à la reprise (nécessite une resync au réveil) ou à la source d’horloge. Si ce n’est pas synchronisé, corrigez la connectivité ou la configuration du serveur NTP.

Task 5: Inspect the last sync and current offset (timesyncd)

cr0x@server:~$ timedatectl timesync-status
       Server: 10.0.0.53 (ntp.corp)
Poll interval: 32min 0s (min: 32s; max 34min 8s)
         Leap: normal
      Version: 4
      Stratum: 3
    Reference: 3B4E2A91
    Precision: 1us (-24)
Root distance: 18.525ms
       Offset: +1.842ms
        Delay: 2.913ms
       Jitter: 0
 Packet count: 109
    Frequency: -12.345ppm

Signification : Un offset en millisecondes est sain. Root distance et stratum vous donnent une idée de la qualité. Des offsets gigantesques (secondes+) signifient que votre guest est instable ou non synchronisé.

Décision : Si l’offset est petit mais que vous voyez toujours des erreurs TLS, votre problème peut être le fuseau horaire, un DNS en cache, ou la chaîne de certificats — pas forcément une dérive temporelle.

Task 6: If you’re using chrony, confirm sources and tracking

cr0x@server:~$ chronyc tracking
Reference ID    : 0A000035 (10.0.0.53)
Stratum         : 4
Ref time (UTC)  : Thu Feb 05 14:22:24 2026
System time     : 0.000001234 seconds fast of NTP time
Last offset     : -0.000000321 seconds
RMS offset      : 0.000012345 seconds
Frequency       : 15.123 ppm slow
Residual freq   : -0.001 ppm
Skew            : 0.020 ppm
Root delay      : 0.002911 seconds
Root dispersion : 0.000812 seconds
Update interval : 64.0 seconds
Leap status     : Normal

Signification : « System time … fast/slow of NTP time » vous indique votre erreur. Sain = proche de zéro, fréquence stable, état de saut normal.

Décision : Si chrony n’affiche aucune référence ou de grands offsets, vous ne vous synchronisez pas réellement. Corrigez le réseau ou la configuration du serveur avant d’accuser WSL.

Task 7: Verify name resolution and basic connectivity (because NTP can fail quietly)

cr0x@server:~$ getent hosts ntp.corp
10.0.0.53        ntp.corp

Signification : DNS résout le nom NTP. Si ce n’est pas le cas, timesync échouera même si le réseau est en apparence correct.

Décision : Si la résolution DNS échoue, corrigez les problèmes de génération de resolv.conf de WSL2 ou l’accès au DNS d’entreprise avant de toucher aux services temporels.

Task 8: Check UDP/123 reachability indirectly (no fancy tools required)

cr0x@server:~$ sudo timeout 3 bash -c 'cat < /dev/null > /dev/udp/10.0.0.53/123' && echo ok || echo blocked
ok

Signification : C’est un test grossier : il ne prouve pas les réponses NTP, mais « blocked » suggère des problèmes de routage/firewall/politique.

Décision : Si c’est bloqué, arrêtez d’essayer des serveurs NTP publics au hasard ; vous avez besoin d’un chemin temporel approuvé par l’entreprise (ou d’utiliser la synchronisation fournie par l’hôte).

Task 9: Look for suspend/resume patterns in dmesg

cr0x@server:~$ dmesg | tail -n 20
[  812.345678] systemd[1]: Started Network Time Synchronization.
[ 5432.123456] PM: suspend entry (s2idle)
[ 5432.234567] Freezing user space processes
[ 5432.345678] PM: suspend exit
[ 5432.456789] systemd-timesyncd[319]: Network configuration changed, trying to establish connection.

Signification : Si vous voyez des marqueurs suspend/resume puis une réinitialisation de la synchro, vous traitez probablement une horloge obsolète post-reprise.

Décision : Implémentez un hook de resync post-reprise (dans le contexte WSL : redémarrer WSL ou déclencher le redémarrage du service temps) plutôt que de définir l’heure manuellement.

Task 10: Confirm the guest is actually WSL2 and see version info

cr0x@server:~$ uname -a
Linux cr0x-wsl 5.15.146.1-microsoft-standard-WSL2 #1 SMP Fri Jan 10 18:20:00 UTC 2026 x86_64 GNU/Linux

Signification : La chaîne du noyau inclut la marque Microsoft WSL2. L’âge du noyau compte ; des améliorations de tenue du temps arrivent dans les noyaux plus récents.

Décision : Si votre noyau est ancien, mettez à jour WSL. Ne déboguez pas une tenue du temps d’ère 2020 si vous pouvez installer des correctifs de 2026.

Task 11: Detect “time went backwards” symptoms in logs (a classic red flag)

cr0x@server:~$ journalctl -b -p warning --no-pager | grep -i time | tail -n 5
Feb 05 14:05:01 cr0x-wsl systemd[1]: Time has been changed
Feb 05 14:05:01 cr0x-wsl systemd[1]: Detected clock change. Skipping time warp.

Signification : Des sauts temporels ont eu lieu. Pas forcément fatal, mais cela explique les builds instables et les erreurs « not yet valid ».

Décision : Si le temps saute souvent, concentrez-vous sur une discipline stable (chrony) et des hooks de reprise, pas sur des corrections manuelles.

Task 12: Reproduce the failure in a controlled way (TLS validity check)

cr0x@server:~$ curl -Iv https://example.internal 2>&1 | sed -n '1,15p'
*   Trying 10.0.1.25:443...
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* SSL certificate problem: certificate is not yet valid
* Closing connection 0
curl: (60) SSL certificate problem: certificate is not yet valid

Signification : « Not yet valid » indique souvent que l’horloge cliente est en retard par rapport au timestamp NotBefore du certificat. Cela peut aussi être dû à un proxy qui intercepte TLS avec des certificats récents. Mais le temps est le suspect numéro un.

Décision : Comparez date avec l’heure Windows et avec la fenêtre de validité du certificat (tâche suivante). Si le décalage est réel, corrigez l’heure avant de chercher dans les magasins de certificats.

Task 13: Inspect certificate validity dates to prove it’s time, not “mystery TLS”

cr0x@server:~$ echo | openssl s_client -connect example.internal:443 -servername example.internal 2>/dev/null | openssl x509 -noout -dates
notBefore=Feb  5 14:10:00 2026 GMT
notAfter=May  6 14:10:00 2026 GMT

Signification : Si votre heure WSL2 est antérieure à notBefore, TLS échoue exactement comme montré.

Décision : Arrêtez de discuter avec TLS. Réglez l’horloge.

Task 14: Quick, low-risk “kick” — restart WSL from Windows side

cr0x@server:~$ powershell.exe -NoProfile -Command "wsl --shutdown"

Signification : Cela arrête toutes les instances WSL. Au prochain lancement, la VM démarre proprement et récupère souvent l’heure correcte de l’hôte.

Décision : Si cela corrige systématiquement le problème, la cause racine est le comportement de reprise. Vous voulez quand même une solution durable, mais maintenant vous avez un contournement sûr.

Task 15: Validate whether your time daemon is stepping the clock (dangerous) or slewing (preferred)

cr0x@server:~$ chronyc -n sourcestats | head
Name/IP Address            NP  NR  Span  Frequency  Freq Skew  Offset  Std Dev
10.0.0.53                   7   4   256     +0.012      0.034   +0.000   0.001

Signification : Une fréquence stable et de petits offsets indiquent une discipline par « slewing ». Si vous voyez des corrections violentes, vous pourriez effectuer des « steps » fréquents, ce qui casse des applications.

Décision : Configurez chrony pour effectuer des steps seulement au démarrage puis slewer ensuite, sauf cas particulier.

Correctifs efficaces (et pourquoi)

Il y a trois niveaux de correctifs : mettre à jour/activer la plomberie, exécuter un vrai démon de synchronisation, et gérer la mise en veille/reprise. Faites-les dans cet ordre. Évitez de « régler l’heure dans un cron » sauf si votre objectif est de créer de nouveaux modes de panne passionnants.

1) Gardez WSL et l’heure Windows sains

Si l’heure Windows est fausse, tout en aval devient théâtre. Corrigez d’abord la synchronisation de l’heure Windows (les machines jointes au domaine devraient déjà être disciplinées). Sur les machines non jointes, assurez-vous que le service Windows Time tourne et n’est pas bloqué par la politique VPN. Ensuite, mettez à jour WSL pour ne pas rester coincé avec un comportement de noyau ancien.

2) Activez systemd dans WSL (si possible)

Les versions modernes de WSL prennent en charge systemd quand il est configuré. Avoir systemd rend la synchronisation de l’heure un problème Linux normal, ce qui est un cadeau. Vous pouvez exécuter systemd-timesyncd (simple) ou chrony (mieux en conditions difficiles).

Si vous ne pouvez pas ou ne voulez pas activer systemd, vous pouvez toujours exécuter chrony de manière plus manuelle, mais vous perdrez les hooks de cycle de vie propres qui rendent cela fiable.

3) Préférez chrony quand la dérive est chronique

systemd-timesyncd convient pour beaucoup de portables de développement. Mais les schémas de dérive WSL2 — surtout après mise en veille et sous contention CPU — bénéficient souvent de la robustesse de chrony et de son meilleur suivi/pilotage.

chrony gère aussi mieux les réseaux intermittents et les longs intervalles entre opportunités de sync. C’est la description de poste d’une VM sur portable.

4) Gérez explicitement la reprise

Si la dérive apparaît après mise en veille/hibernation, vous voulez un déclencheur explicite de resynchronisation. Une approche propre est de redémarrer le démon horaire (ou même WSL) au réveil. Le « hook » correct dépend si vous le gérez depuis Windows (Planificateur de tâches) ou depuis Linux (unités systemd et timers). Dans une flotte d’entreprise, la remédiation pilotée par Windows est souvent plus simple à déployer.

Blague n°2 : Un portable qui se réveille d’une mise en veille est en gros un petit exercice de reprise après sinistre — juste avec moins de postmortems et plus de café.

Modèle de configuration chrony qui se comporte en production

Sur un réseau d’entreprise, vous avez souvent un serveur NTP interne. Utilisez-le. Les NTP publics au hasard depuis l’intérieur d’un VPN verrouillé, c’est la manière la plus rapide de passer un jeudi à expliquer l’egress UDP à la sécurité.

Exemple : installer et configurer chrony (les commandes diffèrent selon la distro). Voici une configuration orientée Debian/Ubuntu :

cr0x@server:~$ sudo apt-get update
Hit:1 http://archive.ubuntu.com/ubuntu jammy InRelease
Reading package lists... Done

Signification : Si cela échoue avec « Release file is not valid yet », votre horloge est en retard. Corrigez l’heure avant de continuer.

Décision : Si update a réussi, poursuivez l’installation de chrony.

cr0x@server:~$ sudo apt-get install -y chrony
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  chrony
Setting up chrony (4.4-1ubuntu0.1) ...
Created symlink /etc/systemd/system/multi-user.target.wants/chrony.service → /lib/systemd/system/chrony.service.

Signification : chrony est installé et activé comme service.

Décision : Configurez-le pour pointer vers des serveurs autorisés et pour effectuer des steps seulement au démarrage.

cr0x@server:~$ sudo bash -c 'cat >/etc/chrony/chrony.conf <<EOF
pool ntp.corp iburst
driftfile /var/lib/chrony/chrony.drift
makestep 1.0 3
rtcsync
logdir /var/log/chrony
EOF'

Signification : makestep 1.0 3 permet de stepper si l’offset >1s pour les 3 premières mises à jour. Après cela, il slewe. C’est un équilibre sain pour les bizarreries de reprise sur portable sans casser constamment les charges en cours.

Décision : Redémarrez et vérifiez le tracking.

cr0x@server:~$ sudo systemctl restart chrony

cr0x@server:~$ chronyc sources -v
  .-- Source mode  '^' = server, '=' = peer, '#' = local clock.
 / .- Source state '*' = current best, '+' = combined, '-' = not combined.
| /   Reachability register (octal) - '>377' means good.
||                                                              
^* 10.0.0.53                       3   6   377    12   +0us[ +5us] +/-  20ms

Signification : Le * indique la source sélectionnée. Reachability 377 est excellent. L’offset est minuscule.

Décision : Si vous n’obtenez pas de source et que la reach reste faible (0 ou 1), c’est une politique réseau ou DNS. Corrigez cela en amont.

Remédiation après reprise : l’approche pragmatique

Sur les portables affectés, l’action « corriger maintenant » la plus cohérente est de redémarrer WSL. C’est brutal, mais efficace. Pour une station de dev, c’est souvent acceptable. Pour des processus long-running dans WSL, moins.

Si vous ne pouvez pas vous permettre un arrêt complet de WSL, redémarrez le service horaire dans la distro après la reprise. Si systemd est activé, c’est simple.

cr0x@server:~$ sudo systemctl restart systemd-timesyncd

Signification : Force timesyncd à réévaluer le réseau et à resynchroniser.

Décision : Si timesyncd ne se synchronise pas après reprise, passez à chrony ou adressez la reachabilité NTP.

Erreurs courantes : symptômes → cause racine → correction

Voici les récidivistes. Si vous en reconnaissez un, vous pouvez éviter des heures de tâtonnements « peut-être c’est DNS ».

1) Symptom: “SSL certificate is not yet valid” inside WSL2 only

Cause racine : L’heure du guest WSL2 est en retard après mise en veille/reprise ; l’heure Windows est correcte.
Correction : Activez chrony ou timesyncd ; implémentez une resync post-reprise ; contournement rapide : wsl --shutdown puis relance.

2) Symptom: `apt-get update` says “Release file is not valid yet”

Cause racine : L’horloge du guest est en retard par rapport au timestamp des métadonnées du dépôt.
Correction : Corrigez d’abord l’heure. Ne désactivez pas les vérifications de date des dépôts ; c’est une régression de sécurité déguisée en commodité.

3) Symptom: time is off by exactly your timezone offset

Cause racine : Mauvaise configuration du fuseau horaire dans la distro, pas une dérive.
Correction : Réglez le fuseau horaire avec timedatectl set-timezone (systemd) ou les outils distro spécifiques. Gardez l’horloge en UTC ; affichez l’heure locale si nécessaire.

4) Symptom: time correct at boot, drifts during heavy CPU load

Cause racine : Le guest ne reçoit pas de tranches CPU fiables ; discipline temporelle trop faible ; noyau/WSL ancien.
Correction : Mettez à jour WSL/noyau ; utilisez chrony ; réduisez la famine CPU extrême ; évitez d’assigner à WSL des ressources minimales qui brisent la tenue du temps.

5) Symptom: chrony/timesyncd can’t reach any server on VPN

Cause racine : Le réseau d’entreprise bloque UDP/123 ; NTP autorisé seulement vers des serveurs internes ou via un proxy spécial.
Correction : Pointez votre service temporel vers les serveurs NTP approuvés ; si aucun n’existe, escaladez vers réseau/sécurité pour un chemin approuvé. Ne tunnelisez pas vers des NTP publics depuis des endpoints d’entreprise.

6) Symptom: “System clock synchronized: yes” but apps still complain about time

Cause racine : L’application utilise des tokens/certs mis en cache créés pendant la dérive ; ou le problème est monotone vs horloge murale ; ou ce n’est pas du tout le temps.
Correction : Redémarrez/actualisez les processus affectés après correction de l’heure ; vérifiez avec les dates de certificats ; confirmez l’horloge murale avec date -Is et comparez.

7) Symptom: “time went backwards” warnings in journald frequently

Cause racine : Steps répétés à cause d’une configuration agressive ou d’une source d’heure instable ; ou la reprise provoque un grand saut en arrière.
Correction : Utilisez chrony avec des steps contrôlés (makestep seulement en début) et du slewing ensuite ; implémentez une resync au réveil pour éviter de gros sauts.

Mini-histoires d’entreprise depuis les tranchées des décalages horaires

Mini-histoire 1 : L’incident causé par une mauvaise hypothèse

L’entreprise avait un environnement mixte Windows/Linux, et WSL2 était la norme officieuse. Tout allait bien jusqu’à ce que l’équipe déploie un nouveau dépôt interne avec des certificats TLS à courte durée de vie délivrés par une CA interne. La CA était correctement gérée. Les certificats étaient valides. Le dépôt était ennuyeux au meilleur sens.

Puis les builds ont commencé à échouer. Pas tous. Pas même la plupart. Juste un ensemble tournant de développeurs, surtout des utilisateurs de portables, surtout ceux qui fermaient leur couvercle entre les réunions. L’erreur était cohérente : « certificate is not yet valid. » Les équipes sécurité ont été alertées. L’équipe du dépôt a été blâmée. Quelqu’un a suggéré que l’horloge de la CA était fausse (elle ne l’était pas).

La mauvaise hypothèse était simple : « Si l’heure Windows est correcte, l’heure WSL doit l’être aussi. » C’est rassurant, comme croire que vos sauvegardes sont bonnes parce que le tableau de bord est vert. Un SRE a finalement demandé à un développeur d’exécuter date dans WSL2 à côté de l’horloge Windows. Le guest avait sept minutes de retard. Suffisant pour échouer devant la limite NotBefore du certificat.

La correction n’était pas héroïque. Ils ont activé un service de synchronisation correct dans WSL2, l’ont pointé vers les serveurs NTP internes déjà utilisés par les hôtes Linux, et ont ajouté un léger job « resync-on-resume » sur Windows qui redémarrait WSL pour le groupe d’utilisateurs le plus affecté. Une fois le temps stable, les erreurs TLS ont disparu. L’équipe CA a arrêté de recevoir des mails en colère. L’équipe du dépôt aussi. Tout le monde est retourné à ignorer le temps — jusqu’au prochain incident, parce que c’est comme ça que les humains fonctionnent.

Mini-histoire 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation avait une initiative d’autonomie de batterie. Ils ont ajusté les portables pour l’« efficacité », ce qui incluait des politiques de veille agressives et des économies d’énergie CPU. Quelqu’un a aussi recommandé de limiter les services en arrière-plan. Dans WSL2, les développeurs ont commencé à réduire les services pour diminuer « l’overhead », bien sûr. Certains ont même désactivé les démons de synchronisation horaire avec la logique : « je ne suis pas un serveur. »

Un mois plus tard, des échecs d’auth intermittents sont apparus contre un service interne reposant sur Kerberos. Encore : pas tout le monde, pas tout le temps. Les échecs tendaient à survenir l’après-midi, souvent après une longue réunion. Les développeurs ont blâmé le VPN. Le VPN a blâmé le DNS. Le DNS a blâmé « quelque chose avec Linux ». Le triangle corporatif classique de la culpabilité.

Le vrai coupable était la dérive d’horloge dans WSL2 après des cycles répétés de mise en veille/reprise, aggravée par l’optimisation : pas de démon de temps pour corriger. La tolérance Kerberos n’est pas une suggestion. Quand la dérive franchit le seuil, les tickets sont rejetés. Les échecs ressemblaient à des « mauvais mots de passe » côté application, ce qui est une blague cruelle des protocoles.

Le rollback était simple : réactiver la synchronisation horaire et assouplir les réglages de veille les plus agressifs pour les développeurs qui utilisaient beaucoup WSL2. L’autonomie a légèrement diminué. La productivité s’est significativement rétablie. La leçon est arrivée comme toutes les leçons : « votre portable n’est pas un serveur, mais il exécute des systèmes qui tiennent au temps comme un serveur. »

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une équipe proche des finances exécutait localement un pipeline build-and-release dans WSL2 parce que la capacité CI d’entreprise était limitée. Ce n’était pas idéal, mais c’était la réalité. Le lead d’équipe avait une règle non négociable : chaque environnement dev doit pointer vers les mêmes sources NTP internes que les hôtes Linux de production, et cela doit être vérifiable.

Ils ont standardisé sur chrony dans WSL2, avec une configuration gérée via un petit script de bootstrap. Ils ne faisaient pas confiance au « marche sur ma machine ». Ils faisaient confiance à « chronyc tracking montre un faible offset ». Ils enregistraient aussi un signal de santé simple : une vérification quotidienne qui consignait offset et stratum dans un fichier local. Pas parce que c’était glamour — parce que cela rendait le temps mesurable.

Un jour, une modification réseau d’entreprise a accidentellement bloqué UDP/123 sur un sous-ensemble de VLAN Wi-Fi. Les développeurs ont commencé à voir des problèmes étranges ailleurs, mais cette équipe a détecté le problème de temps tôt parce que leur vérification quotidienne a commencé à signaler l’absence de sources atteignables. Ils avaient des preuves, pas des impressions.

Pendant que d’autres se disputaient sur « Internet est en panne ? », cette équipe a basculé temporairement vers une source NTP approuvée alternative sur un segment réseau différent et a continué à délivrer. Plus tard, le réseau a corrigé la politique. Personne n’a écrit un postmortem dramatique. Voilà à quoi ressemble le succès : ennuyeux, correct, et majoritairement invisible.

Listes de vérification / plan étape par étape

Checklist A: Stabilisation unique (faire une fois par machine)

Mettre à jour WSL et le noyau (côté Windows) et redémarrer si nécessaire.
Confirmer que l’heure Windows est disciplinée (temps de domaine ou synchronisation fiable).
Dans WSL2, confirmer le statut de systemd (ps -p 1).
Activer un démon de synchronisation horaire :
- Si systemd est présent et que vous voulez simple : activez systemd-timesyncd.
- Si vous observez une dérive chronique : installez et exécutez chrony.
Pointez vers des sources NTP approuvées (NTP interne si en entreprise ; sinon pools publics stables si autorisés).
Vérifiez l’offset (statut timesyncd ou chronyc tracking).

Checklist B: Fiabilité post-mise en veille (le plan « réalité portable »)

Reproduire le bug : fermez le couvercle 5–10 minutes, reprenez, exécutez date -Is.
Si la dérive se produit : choisissez entre :
- Contournement rapide : redémarrer WSL (wsl --shutdown).
- Correction durable : implémenter un redémarrage déclenché par la reprise du service (timesyncd/chrony) ou un redémarrage WSL via le Planificateur de tâches Windows.
Après implémentation : répétez le test veille/reprise et vérifiez que l’offset reste faible.

Checklist C: Quand les réseaux d’entreprise gênent

Supposez que UDP/123 est bloqué jusqu’à preuve du contraire.
Trouvez des serveurs temporels approuvés (NTP interne, contrôleurs de domaine, ou sources temporelles sanctionnées).
Configurez votre démon pour n’utiliser que ces serveurs.
Vérifiez l’atteignabilité et le tracking avec chrony/timesyncd.
Si aucun n’existe : escaladez. Le temps est une dépendance de sécurité, pas un choix personnel.

FAQ

1) Pourquoi WSL2 dérive-t-il plus que « Linux nu » sur bare metal ?

Parce que c’est une VM avec un modèle de planification et de timers différent, et la mise en veille d’un portable ajoute des discontinuités. Le bare metal a généralement un comportement de timers matériels plus serré et moins d’edge cases de mise en veille pour le guest.

2) Dois-je juste exécuter `sudo date -s` quand ça arrive ?

Non. Régler l’heure manuellement provoque des sauts qui peuvent casser des processus en cours et masque le vrai problème : l’absence d’une discipline continue. Utilisez un démon de temps et corrigez le comportement de reprise.

3) Est-ce que `systemd-timesyncd` suffit, ou ai-je besoin de chrony ?

timesyncd suffit quand le réseau est stable et la dérive faible. Si vous voyez des décalages répétés après mise en veille, une connectivité intermittente, ou de grandes corrections, chrony est généralement l’outil recommandé.

4) Mon WSL2 n’a pas systemd. Suis-je bloqué ?

Vous n’êtes pas bloqué, mais vous jouez en mode difficile. Vous pouvez activer systemd dans WSL (recommandé) ou exécuter chrony sans supervision systemd. Cette dernière option fonctionne, mais est plus facile à mal configurer et plus difficile à maintenir.

5) Pourquoi la dérive horaire casse-t-elle `apt` et `git` si dramatiquement ?

apt valide les timestamps des métadonnées du dépôt ; TLS valide les fenêtres de validité des certificats. Les deux sont des fonctionnalités de sécurité. Une heure incorrecte ressemble à une attaque ou à une corruption, donc le comportement correct est d’échouer.

6) Docker dans WSL2 peut-il aggraver ça ?

Docker en lui-même ne « cause » pas la dérive, mais des charges containers lourdes peuvent augmenter la contention CPU. Si le guest est affamé ou que votre démon de temps est absent/mal configuré, la dérive devient visible plus rapidement.

7) Pourquoi mes logs semblent-ils dans le désordre ?

Si l’horloge murale saute en arrière ou en avant, les horodatages des logs suivent. Vos systèmes peuvent fonctionner, mais votre observabilité devient peu fiable. Utilisez une horloge monotone pour les durées, et maintenez l’horloge murale disciplinée.

8) Quel offset temporel est acceptable pour du travail dev ?

Gardez-le dans la seconde si possible ; quelques secondes suffisent pour la plupart des tâches. Une fois dans les minutes, attendez-vous à des échecs d’auth et TLS. Dans des environnements d’entreprise stricts, même un petit décalage peut être problématique.

9) Si l’heure Windows est correcte, pourquoi WSL2 ne l’hérite-t-il pas parfaitement ?

Parce que « hériter » n’est pas un flux constant ; c’est médié par l’intégration de virtualisation et le comportement du guest. Mise en veille/reprise, délais de planification, et configuration du guest peuvent encore produire de la dérive.

10) Est-il sûr de redémarrer fréquemment WSL ?

C’est sûr au sens où c’est une opération supportée. Ce n’est pas sûr pour l’état non sauvegardé : cela tue les processus en cours dans WSL. Traitez-le comme le redémarrage d’une VM : bien quand c’est planifié, impoli quand c’est fait en plein travail.

Étapes suivantes que vous pouvez réellement faire aujourd’hui

Faites ceci dans l’ordre. Arrêtez quand le problème cesse.

Mesurez : exécutez date -Is et timedatectl dans WSL2. Confirmez si c’est une dérive ou un fuseau horaire.
Confirmez le service de sync : si systemd est présent, vérifiez systemctl status systemd-timesyncd (ou chrony si installé).
Corrigez les bases : activez un démon (timesyncd ou chrony), pointez-le vers des sources approuvées, vérifiez l’offset.
Gérez la mise en veille : si la dérive apparaît après reprise, implémentez une action déterministe — redémarrer le service temps ou, si nécessaire, redémarrer WSL — déclenchée après le réveil.
Validez par un test d’échec : répétez le contrôle de validité TLS et la mise à jour du dépôt. Ne déclarez pas victoire tant que le symptôme original n’a pas disparu.

Si vous retenez un seul conseil orienté : considérez le temps comme une infrastructure, même sur un portable. Surtout sur un portable. Vos outils sont maintenant des systèmes distribués qui portent un hoodie.