Зсув часу в WSL2: виправте неточність годинника правильно

February 20, 2026 • February 20, 2026 • Читання: 5 хв • Views: 0

Було корисно?

Коли час у WSL2 відхиляється, нічого не ламається чемно. Git fetch запалює помилки TLS. Менеджери пакетів заявляють, що метадані репозиторію «з майбутнього». Логи стають вигадкою. А ваша хронологія інциденту — вже тендітна — перетворюється на інтерпретативний танець.

Найгірше: здається, що це випадково. Ви закриваєте ноутбук, ідете на зустріч, повертаєтеся — і раптом ваша Linux-середа вважає, що зараз минулий вівторок. Виправимо це по-дорослому: спочатку виміряємо, потім синхронізуємо правильний годинник і припинимо заклеювати зсув хеками, що змушують засоби безпеки верещати.

Як виглядає зсув часу в WSL2 (і чому це важливо)

Зсув годинника — це одна з тих проблем «лише кілька хвилин», яка може зупинити весь пайплайн. У продакшні час — це контракт API: дійсність сертифікатів TLS, квитки Kerberos, термін дії токенів OAuth, кореляція логів, спани розподіленого трасування, інвалідція кешу, відтворюваність збірок. Порушите час — порушите довіру.

WSL2 додає нюанс: це Linux-VM під Hyper-V з власним ядром. Тому час може дрейфувати на рівні гостя, навіть коли Windows виглядає нормально. Переходи в сон/гібернацію та навантаження хоста можуть погіршувати ситуацію. Дехто отримує WSL2-інстанс, який відновлюється зі застарілим годинником; інші бачать періодичний дрейф під тривалим навантаженням CPU або коли гостьовій ОС рідко виділяють процесор.

Дві швидкі реалії:

Правильний час у Windows не гарантує правильний час у WSL2.
Вирішувати проблему «простим встановленням дати» всередині гостя — тимчасовий пластир. Це навіть може створити проблеми з безпекою, маскуючи відсутність надійного джерела часу.

Жарт №1: Зсув часу — як технічний борг: ви ігноруєте його, поки він не «нарахує відсотків» під час інциденту.

Цікаві факти та історичний контекст (ви станете розумніші наприкінці)

NTP старший за багато сучасних ОС. Протокол мережевого часу існує з початку 1980-х і досі є основою синхронізації часу в інтернеті.
Синхронізація годинника — це не лише «встановити час». Сучасні реалізації поступово коригують годинник, щоб не зламати програми, чутливі до часу.
Час у віртуалізованому середовищі завжди був дивним. Ранні платформи віртуалізації боролися з апаратними перериваннями таймерів і плануванням, через що гості «бігали» швидше або повільніше під навантаженням.
Монотонний vs настінний годинник має значення. У Linux є монотонний годинник для вимірювання інтервалів; настінний годинник може скакати через NTP-корекції або ручні зміни.
Kerberos відомо нетерпимий до зсуву. Типові допуски — хвилини, не години. Поза цим аутентифікація падає, і це виглядає як «зламані облікові дані».
TLS покладається на час для базової безпеки. Вікно дійсності сертифікатів — простий контроль, що зупиняє повторне відтворення та зловживання. Неправильний час робить безпечні системи «зламаними».
Секунди-стрибки (leap seconds) — реальність. Вони рідкісні, але спричиняли інциденти, коли системи не погоджувалися щодо їхнього оброблення.
Windows і Linux відрізняються в припущеннях щодо часу. Історично дуель у dual-boot про те, чи апаратний годинник локальний час чи UTC, навчила покоління поважати точність часу.

Як WSL2 підтримує час: складові

WSL2 — це легка VM з реальним ядром Linux. Вона має багато спільного з гостьовими системами Hyper-V: віртуальні таймери, шину віртуалізації та механізми інтеграції, що дозволяють гостю співпрацювати з хостом. Але «легка» не означає «захищена від проблем з часом». Це просто означає, що режими відмови підступніші.

Три годинники, які слід розрізняти

Годинник Windows-хоста: що показує панель задач; зазвичай керується службою Windows Time (w32time) або доменною синхронізацією.
Годинник гостя WSL2: що показує date у Linux; може дрейфувати або відновлюватися застарілим після сну.
Монотонні годинники: використовуються для вимірювання тривалостей; рідко причина помилки «TLS ще не дійсний», але актуальні при дивних таймаутах або поведінці планувальника.

Чому сон/гібернація — звичайний винуватець

Коли ноутбук засинає, виконання CPU зупиняється. Коли він прокидається, хост оновлює свій час, але гостьова VM може не одержати миттєвого коректного сигналу синхронізації. Якщо VM призупинена або її джерело часу віртуальне і не коригується оперативно, ви можете відновитися з годинником, що відстає. Чим частіше спите — тим більше дрейфу. Це не містика; це відновлення стану.

Чому «просто запустити ntpdate» — не правильний інстинкт

Одноразові стрибки часу можуть зламати працюючі процеси. Бази даних, інструменти збірки та все, що покладається на часові мітки, може працювати некоректно. Правильний підхід — увімкнути службу синхронізації, яка дисциплінує годинник (поступові корекції), і виправити корінну причину (ресинхронізація після відновлення, інтеграція WSL2, стабільність часу хоста).

Парафраз ідеї (не дослівно) від Річарда Кука, дослідника надійності: Відмови рідко бувають одноточковими; вони виникають через те, що нормальні припущення несприятливо накладаються.

Швидкий план діагностики

Це потік «ви на виклику, все падає, і треба зрозуміти, що не так за п’ять хвилин». Не ускладнюйте.

Перше: підтвердіть зсув і його напрямок

Перевірте час Windows порівняно із зовнішнім джерелом (або принаймні переконайтеся, що Windows не сильно відстає).
Перевірте час у WSL2 всередині дистрибутива.
Обчисліть дельту. Секунди? Хвилини? Години? Масштаб змінює ймовірну корінну причину.

Друге: вирішіть, чи гість може дістатися джерела часу

Перевірте DNS і доступність вихідного UDP/123 (або хоча б HTTPS-доступ до корпоративних проксі часу, якщо у вас така інфраструктура).
Перевірте, чи існує служба часу і чи вона запущена (systemd-timesyncd, chrony).

Третє: ізолюйте хост vs гість vs мережеву політику

Якщо Windows неправильний: виправте час у Windows перш за все. Гість на неправильному хості — не проблема гостя.
Якщо Windows правильний, а WSL2 неправильний: виправте механізм синхронізації WSL2 і поведінку після відновлення.
Якщо обидва іноді правильні і іноді ні після сну: реалізуйте ресинхронізацію після прокидання і перевірте оновлення WSL/ядра.
Якщо тільки корпоративна мережа ламає синхронізацію: ймовірно, у вас блокується NTP і потрібно дозволене джерело часу або інший підхід.

Практичні завдання: команди, виводи, рішення (12+)

Це практичні перевірки, які ви можете виконати просто зараз. Кожне завдання містить: команду, що типовий вивід означає, і як прийняти рішення за результатом.

Завдання 1: негайно перевірте настінний годинник WSL2

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

Значення: ISO-8601 настінний час всередині WSL2. Порівняйте його з Windows або з відомим еталоном.

Рішення: Якщо він відстає більше ніж приблизно 2 хвилини — вважайте це реальною проблемою. Якщо відмінність у годинах — підозрюйте відновлення після сну/гібернації або ручні зміни.

Завдання 2: перевірте часовий пояс і чи це «плутанина з часовим поясом», а не дрейф

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

Значення: Якщо «Local time» відповідає очікуванням, але «Time zone» неправильний, ви можете бачити зміщення через часовий пояс. Якщо «System clock synchronized» — no і NTP неактивний, гість не дисциплінує годинник.

Рішення: Якщо NTP неактивний — потрібно ввімкнути службу часу (systemd-timesyncd або chrony). Якщо часовий пояс неправильний — виправте його окремо; не ганяйтеся за «дрейфом», що насправді є зміщенням.

Завдання 3: переконайтеся, що systemd справді працює (WSL2 залежить від конфігурації)

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

Значення: Якщо PID 1 — systemd, ви можете використовувати systemd-сервіси як завжди. Якщо це щось інше (наприклад, init або bash), доведеться застосувати інший підхід (або ввімкнути systemd у WSL).

Рішення: Якщо systemd не PID 1, вирішіть, чи ввімкнете systemd (рекомендовано для «повноцінного Linux») або запустите chrony вручну.

Завдання 4: якщо systemd є, перевірте статус timesync-сервісу

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)"

Значення: «Synchronized» — це бажаний стан. Якщо там написано «No network connectivity» або «Timed out», маршрут мережі до NTP блокується або неправильно налаштований.

Рішення: Якщо сервіс активний і синхронізований, мабуть, проблема пов’язана з відновленням після сну (потрібен ресинк) або джерелом годинника. Якщо не синхронізовано — виправляйте підключення або конфіг сервера NTP.

Завдання 5: перевірте останню синхронізацію та поточний зсув (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

Значення: Зсув у мілісекундах — це добре. Root distance і stratum дають відчуття якості джерела. Великі зсуви (секунди+) означають, що гість нестабільний або не синхронізований.

Рішення: Якщо зсув малий, але ви все ще бачите помилки TLS, проблема може бути в часовому поясі, кешованому DNS або ланцюжку сертифікатів — не поспішайте звинувачувати тільки час.

Завдання 6: якщо ви використовуєте chrony, підтвердіть джерела та відстеження

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

Значення: «System time … fast/slow of NTP time» показує вашу помилку. Здорово, якщо близько до нуля, стабільна частота і нормальний leap status.

Рішення: Якщо chrony показує відсутність референсу або великі зсуви — ви фактично не синхронізуєтесь. Виправте мережу або конфіг серверів, перш ніж звинувачувати WSL.

Завдання 7: перевірте розв’язування і базову мережеву доступність (бо NTP може тихо падати)

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

Значення: DNS резолює ім’я NTP. Якщо ні — timesync не працюватиме, навіть якщо мережа загалом у порядку.

Рішення: Якщо DNS не працює — виправте генерацію resolv.conf у WSL2 або доступ до корпоративного DNS, перш ніж чіпати служби часу.

Завдання 8: перевірте доступність UDP/123 непрямо (не потрібні спеціальні інструменти)

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

Значення: Це груба перевірка: вона не доводить відповіді NTP, але «blocked» підказує про проблеми маршруту/фаєрволу/політики.

Рішення: Якщо заблоковано — припиніть експерименти з випадковими NTP-серверами; вам потрібен корпоративно погоджений шлях часу (або синхронізація, надана хостом).

Завдання 9: шукайте шаблони suspend/resume у 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.

Значення: Якщо ви бачите маркери suspend/resume і потім ініціалізацію timesync, швидше за все мова про застарілий час після відновлення.

Рішення: Реалізуйте хук для ресинхронізації після відновлення (у контексті WSL: перезапустіть WSL або тригерніть рестарт служби часу) замість ручного встановлення часу.

Завдання 10: підтвердіть, що гість — саме WSL2, і подивіться версію

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

Значення: Рядок ядра містить брендинг Microsoft WSL2. Вік ядра має значення; покращення таймкіпінгу з’являються в новіших ядрах.

Рішення: Якщо ваше ядро застаріле — оновіть WSL. Не налагоджуйте поведінку 2020 року, якщо можна встановити виправлення 2026 року.

Завдання 11: виявіть симптоми «час пішов назад» у логах (класичний тривожний знак)

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.

Значення: Відбулися стрибки часу. Не завжди фатально, але пояснює нестабільні збірки та помилки «ще не дійсний».

Рішення: Якщо час часто стрибає — зосередьтеся на стабільній дисципліні (chrony) і хук на відновлення, а не на ручних корекціях.

Завдання 12: відтворіть помилку контрольовано (перевірка дійсності TLS)

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

Значення: «Not yet valid» часто вказує, що клієнтський годинник відстає від поля NotBefore сертифіката. Також може бути проксі, який робить TLS-інтерцепцію з новими сертифікатами. Але час — перший підозрюваний.

Рішення: Порівняйте date з часом Windows і періодом дійсності сертифіката (наступне завдання). Якщо зсув реальний — виправте час перед тим, як розглядати магазини сертифікатів.

Завдання 13: перевірте дати дійсності сертифіката, щоб довести, що це про час

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

Значення: Якщо ваш час у WSL2 раніше за notBefore, TLS впаде саме так, як показано.

Рішення: Припиніть сперечатися з TLS. Виправте годинник.

Завдання 14: швидкий, малоризиковий «натиск» — перезапустіть WSL з боку Windows

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

Значення: Це вимикає всі WSL-інстанси. При наступному запуску VM завантажується заново й часто підхоплює правильний час хоста.

Рішення: Якщо це постійно вирішує проблему — корінна причина в поведінці після відновлення. Вам усе одно потрібне стійке рішення, але тепер у вас є безпечний обхідний шлях.

Завдання 15: перевірте, чи служба часу робить «степінг» (стрибок) або «slew» (поступове коригування)

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

Значення: Стабільна частота й малі зсуви вказують на дисципліну через slew. Якщо бачите агресивні корекції —, можливо, відбувається часте step-ування, що ламає додатки.

Рішення: Налаштуйте chrony так, щоб стрибки відбувалися тільки під час старту, а далі — через slew, якщо у вас немає особливих вимог.

Рішення, що працюють (і чому)

Є три рівні виправлень: оновити/увімкнути інфраструктуру, запустити реальну службу синхронізації часу та обробити сон/відновлення. Робіть це в такому порядку. Уникайте «ставити час в cron», якщо ваша мета — не створити нові захоплюючі режими відмов.

1) Підтримуйте WSL і час Windows в порядку

Якщо час Windows неправильний, уся нижча інфраструктура перетворюється на театр. Виправте синхронізацію часу у Windows перш за все (машини у домені мають уже дисциплінований час). На недоменних машинах переконайтеся, що служба Windows Time працює і її не блокує політика VPN. Потім оновіть WSL, щоб не застрягти на старій поведінці ядра.

2) Увімкніть systemd у WSL (якщо можете)

Сучасний WSL підтримує systemd, якщо його налаштувати. Наявність systemd робить синхронізацію часу звичайною Linux-проблемою, а це благодать. Можна запускати systemd-timesyncd (просто) або chrony (краще в складних умовах).

Якщо не можете або не хочете вмикати systemd, ви все одно можете запускати chrony вручну, але втратите чисту службу життя, що робить це надійнішим.

3) Віддавайте перевагу chrony, коли дрейф хронічний

systemd-timesyncd підходить для багатьох ноутбуків розробників. Але схеми дрейфу WSL2 — особливо після сну та під CPU-навантаженням — часто краще витримуються chrony, який має міцніший алгоритм відстеження і керування.

chrony також краще витримує переривчасту мережу і великі проміжки між синхронізаціями. Це фактично опис роботи ноутбук-VM.

4) Обробляйте відновлення явним чином

Якщо дрейф з’являється після сну/гібернації, потрібен явний тригер ресинхронізації. Чистий підхід — перезапустити службу часу (або навіть WSL) після відновлення. «Правильний» хук залежить від того, чи керуєте ви це з Windows (Task Scheduler) або з Linux (systemd-юнити і таймери). У корпоративному парку легше поширювати рішення з боку Windows.

Жарт №2: Ноутбук, що прокидається зі сну — це як маленька відновлювальна вправа для Катастрофи, тільки з меншою кількістю постмортемів і більшою кількістю кави.

Шаблон конфігурації chrony, що поводиться в реальному житті

У корпоративній мережі зазвичай є внутрішній NTP-сервер. Використовуйте його. Випадковий публічний NTP з-під замкненого VPN — це рецепт четвергової зустрічі з безпекою, де ви пояснюєте вихід UDP.

Приклад: встановіть і налаштуйте chrony (команди залежать від дистрибутива). Ось варіант для Debian/Ubuntu:

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

Значення: Якщо це падає з повідомленням «Release file is not valid yet», ваш годинник відстає. Виправте час перед продовженням.

Рішення: Якщо update пройшов — продовжуйте встановлення 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.

Значення: chrony встановлено і ввімкнено як сервіс.

Рішення: Налаштуйте його на дозволені сервери і дозвольте step лише під час старту.

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'

Значення: makestep 1.0 3 дозволяє стрибок, якщо зсув >1s для перших 3 оновлень. Після цього відбувається slewing. Це розумний баланс для ноутбуків, щоб впоратись з відновленням після сну без частих руйнівних стрибків.

Рішення: Перезапустіть і перевірте трекінг.

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

Значення: * вказує на обраний джерело. Reachability 377 — відмінно. Зсув мізерний.

Рішення: Якщо джерело не з’являється і reach залишається низьким (0 або 1), це мережева політика або DNS. Виправляйте це на вищому рівні.

Ремедіація після відновлення: прагматичний підхід

На уражених ноутбуках найпослідовніша «зробити зараз» дія — перезапустити WSL. Це жорстко, але ефективно. Для робочої станції розробника це часто прийнятно. Для довготривалих процесів у WSL — не дуже.

Якщо повний shutdown WSL неприпустимий, перезапустіть службу часу всередині дистрибутива після відновлення. Якщо systemd увімкнено, це просто.

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

Значення: Примусово змушує timesyncd перевірити мережу і ресинхронізуватися.

Рішення: Якщо timesyncd не синхронізується після відновлення — переходьте на chrony або розбирайтеся з доступністю NTP.

Типові помилки: симптом → корінна причина → виправлення

Це повторювані провокатори. Якщо ви впізнаєте один — можете пропустити години «можливо, це DNS» метань.

1) Симптом: «SSL certificate is not yet valid» тільки в WSL2

Корінна причина: час гостя WSL2 відстає після сну/відновлення; Windows має правильний час.
Виправлення: Увімкніть chrony або timesyncd; додайте ресинхронізацію після відновлення; швидкий обхід — wsl --shutdown і перезапуск.

2) Симптом: `apt-get update` пише «Release file is not valid yet»

Корінна причина: час гостя відстає від міток часу метаданих репозиторію.
Виправлення: Виправте час спочатку. Не відключайте перевірки дат репозиторію; це зниження безпеки під виглядом зручності.

3) Симптом: час відрізняється рівно на ваш часовий пояс

Корінна причина: неправильна конфігурація часової зони всередині дистрибутива, а не дрейф.
Виправлення: Встановіть часовий пояс через timedatectl set-timezone (systemd) або за допомогою дистрибутивних інструментів. Тримайте системний годинник у UTC; відображайте локальний час за потреби.

4) Симптом: час правильний при завантаженні, дрейфує під час сильного навантаження CPU

Корінна причина: гість не отримує планувальні кванти регулярно; дисципліна часу занадто слабка; старе ядро/WSL-білд.
Виправлення: Оновіть WSL/ядро; використовуйте chrony; зменшіть крайній CPU-голод; не прив’язуйте WSL до мінімальних ресурсів, якщо це руйнує таймкіпінг.

5) Симптом: chrony/timesyncd не можуть дістатися серверів у VPN

Корінна причина: корпоративна мережа блокує UDP/123; NTP дозволений тільки до внутрішніх серверів або через спеціальний проксі.
Виправлення: Налаштуйте службу часу на погоджені внутрішні NTP-сервери; якщо їх немає — ескалюйте до мережевих/безпекових команд. Час — залежність безпеки, а не особисте побажання.

6) Симптом: «System clock synchronized: yes», але додатки все одно скаржаться на час

Корінна причина: додаток використовує кешовані токени/сертифікати, створені під час зсуву; або проблема в монотонному часі vs настінному; або це взагалі не про час.
Виправлення: Очистіть/перезапустіть уражені процеси після виправлення часу; перевірте дати сертифікатів; підтвердіть настінний час за допомогою date -Is і порівняйте.

7) Симптом: часті попередження «time went backwards» у journald

Корінна причина: повторні стрибки через агресивну конфігурацію або нестабільне джерело часу; або відновлення викликає великий зворотний стрибок.
Виправлення: Використовуйте chrony з контрольованим makestep (тільки на старті) та поступовим slewing; реалізуйте ресинк після відновлення, щоб уникнути великих стрибків.

Короткі корпоративні історії з передової зсуву часу

Міні-історія 1: Інцидент через неправильне припущення

Компанія мала змішане середовище Windows/Linux, і WSL2 був неофіційним стандартом. Усе було добре, поки команда не запровадила новий внутрішній репозиторій пакетів з короткоживучими TLS-сертифікатами, виданими внутрішнім CA. CA була в порядку. Сертифікати були дійсні. Репозиторій був нудним у найкращому значенні.

Потім збірки почали падати. Не всі збірки. Навіть не більшість. Просто обертовий набір розробників, здебільшого користувачі ноутбуків, які закривали кришку між зустрічами. Помилка була послідовна: «certificate is not yet valid». Команди безпеки отримували сповіщення. Команда репозиторію отримувала звинувачення. Хтось припустив, що годинник CA неправильний (неправильно).

Неправильне припущення було просте: «Якщо час у Windows правильний, то час у WSL теж має бути правильним». Це втішна думка, як віра в те, що бекапи хороші, бо дашборд зелений. SRE нарешті змусив розробника запустити date у WSL2 поруч із годинником Windows. Гість відставав на сім хвилин. Цього вистачило, щоб потрапити за межі NotBefore сертифіката.

Виправлення не було героїчним. Вони увімкнули належну службу синхронізації в WSL2, вказали її на внутрішні NTP-сервери, які вже використовувалися на Linux-хостах, і додали легкий «ресинк-після-пробудження» таск на Windows, який перезапускав WSL для найуразливішої групи користувачів. Коли час стабілізувався, помилки TLS зникли. Команди перестали писати сердиті листи. Усі повернулися до ігнорування часу — поки не стався наступний інцидент, бо так люди працюють.

Міні-історія 2: Оптимізація, що дала фіаско

Інша організація мала ініціативу енергоефективності. Вони оптимізували ноутбуки для «ефективності», включно з агресивними політиками сну і енергозбереження CPU. Хтось також рекомендував обмежити фонові служби. В WSL2 розробники почали видаляти сервіси, щоб зменшити «накладні витрати», бо, звісно ж, так і сталося. Дехто навіть відключив служби синхронізації часу з логікою: «я не сервер».

Через місяць з’явилися періодичні помилки аутентифікації проти внутрішнього сервісу на Kerberos. Знову: не у всіх, не завжди. Помилки зазвичай траплялися після обіду, часто після довгої зустрічі. Розробники звинувачували VPN. VPN — DNS. DNS — «щось з Linux». Класичний корпоративний трикутник взаємних звинувачень.

Справжній винуватець — зсув годинника всередині WSL2 після повторних циклів suspend/resume, ускладнений оптимізацією: відсутність демона часу для виправлення. Толерантність Kerberos — не порада. Коли дрейф перевищив поріг, квитки відхилялися. Помилки виглядали як «неправильний пароль» на рівні додатку — це жорстока іронія протоколів.

Відкат був простий: знову ввімкнути синхронізацію часу і пом’якшити найагресивніші налаштування сну для розробників, які багато використовували WSL2. Життя батареї трохи впало. Продуктивність відновилась. Урок закріпився так, як завжди: «Ваш ноутбук не сервер, але на ньому працюють системи, яким час важливий як серверу».

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Команда, що працювала поруч із фінансами, запускала локальний пайплайн збірки та релізу у WSL2, бо корпоративний CI був завантажений. Це не було ідеально, але така реальність. Керівник команди мав одне непорушне правило: кожне середовище розробника має вказувати на ті самі внутрішні NTP-джерела, що й продукційні Linux-хости, і це має бути перевірно.

Вони стандартизували chrony у WSL2 з конфігом, керованим через невеликий bootstrap-скрипт. Вони не довіряли «працює на моїй машині». Вони довіряли «chronyc tracking показує малий зсув». Також вони логували простий сигнал здоров’я: щоденну перевірку, що заносила offset і stratum у локальний файл. Не тому, що це було гламурно — а тому, що це зробило час вимірюваною властивістю.

Одного дня мережеві зміни випадково заблокували UDP/123 на частині Wi-Fi VLAN. Інші команди почали бачити дивні проблеми, але ця команда швидко виявила проблему, бо їхня щоденна перевірка почала повідомляти про недоступні джерела. Вони мали доказ, а не відчуття.

Поки інші сперечалися про «інтернет упав», ця команда тимчасово переключилася на альтернативне погоджене джерело NTP у іншому сегменті мережі і продовжила релізи. Пізніше мережа виправила політику. Ніхто не писав драматичного постмортему. Ось як виглядає успіх: нудно, правильно і майже непомітно.

Чеклісти / покроковий план

Чекліст A: Одноразова стабілізація (зробіть це одного разу на машину)

Оновіть WSL і ядро (зі сторони Windows) і перезавантажте за потреби.
Підтвердіть, що час Windows дисциплінований (доменно синхронізований або надійний джерело).
Всередині WSL2 підвердіть статус systemd (ps -p 1).
Увімкніть службу синхронізації часу:
- Якщо є systemd і вам потрібна простота: увімкніть systemd-timesyncd.
- Якщо бачите хронічний дрейф: встановіть і запустіть chrony.
Вкажіть погоджені NTP-джерела (внутрішні NTP для корпоративної мережі; інакше стабільні пули, якщо дозволено).
Перевірте зсув (статус timesyncd або chronyc tracking).

Чекліст B: Надійність після сну (план «ноутбук-реальність»)

Відтворіть баг: закрийте кришку на 5–10 хвилин, відновіть, запустіть date -Is.
Якщо дрейф: вирішіть між:
- Швидкий обхід: перезапустити WSL (wsl --shutdown).
- Стійке виправлення: реалізувати тригер рестарту служби (timesyncd/chrony) після відновлення або рестарт WSL через Windows Task Scheduler.
Після впровадження: повторіть тест сон/відновлення і перевірте, що зсув малий.

Чекліст C: Коли корпоративні мережі заважають

Припустіть, що UDP/123 заблоковано, поки не доведено протилежне.
Знайдіть погоджені сервери часу (внутрішні NTP, контролери домену або санкціоновані джерела).
Налаштуйте вашу службу використовувати лише ці сервери.
Перевірте доступність і трекінг через chrony/timesyncd.
Якщо нічого немає: ескалюйте. Час — це залежність безпеки, а не особисте питання.

Часті питання

1) Чому WSL2 дрейфує більше, ніж «звичайний Linux» на залізі?

Тому що це VM з іншою моделлю планування і таймерів, а сон/гібернація ноутбука додає розривів у часі. На «залізі» апаратні таймери зазвичай стабільніші і менше крайових випадків при відновленні.

2) Чи можна просто робити `sudo date -s`, коли це трапляється?

Ні. Ручне встановлення часу викликає стрибки, які можуть зламати працюючі процеси, і ховає справжню проблему: відсутність постійної дисципліни. Використовуйте службу часу і виправляйте поведінку після відновлення.

3) Чи достатньо `systemd-timesyncd`, чи потрібен chrony?

timesyncd підходить, коли мережа стабільна і дрейф незначний. Якщо ви бачите повторний пост-суспенс дрейф, переривчасте підключення або великі корекції — chrony зазвичай кращий вибір.

4) У мене немає systemd у WSL2. Чи я приречений?

Ні, але це гра в складніших умовах. Ви можете ввімкнути systemd у WSL (рекомендовано) або запустити chrony без супервайзингу systemd. Другий варіант працює, але його легше наламатити і важче утримувати в однорідному стані.

5) Чому зсув часу так драматично ламає `apt` і `git`?

apt перевіряє часові мітки метаданих репозиторію; TLS перевіряє періоди дійсності сертифікатів. Обидва — механізми безпеки. Неправильний час виглядає так само, як атака або корупція, тому правильна поведінка — відмовити в роботі.

6) Чи може Docker у WSL2 посилити проблему?

Docker сам по собі не «створює» дрейф, але важкі робочі навантаження в контейнерах можуть збільшити конкуренцію за CPU. Якщо гість відчуває голод або служба часу відсутня/неправильно налаштована — зсув стане помітнішим швидше.

7) Чому мої логи виглядають невпорядковано?

Якщо настінний годинник скаче назад або вперед, часові мітки логів повторюють це. Системи можуть працювати, але спостережуваність стає ненадійною. Використовуйте монотонний час для інтервалів і тримайте настінний годинник дисциплінованим.

8) Яке допустиме відхилення часу для розробки?

Тримайте його в межах секунди, якщо можете; у межах кількох секунд зазвичай нормально для більшості задач. Коли починаються хвилини — очікуйте проблеми з аутентифікацією і TLS. У корпоративних середовищах навіть маленький зсув може бути критичним.

9) Якщо час Windows правильний, чому WSL2 не успадковує його автоматично?

Бо «успадкування» не є постійним потоком; воно опосередковане інтеграцією віртуалізації і поведінкою гостя. Suspend/resume, затримки планування і налаштування гостя все одно можуть спричиняти зсув.

10) Чи безпечно часто перезапускати WSL?

Це безпечно в тому сенсі, що це підтримувана операція. Воно не безпечне для незбереженого стану: перезапуск вбиває працюючі процеси у WSL. Розглядайте це як перезавантаження VM: нормально при плануванні, грубо в середині важливої роботи.

Наступні кроки, які можна зробити сьогодні

Робіть це по порядку. Супиняйтеся, коли проблема зникне.

Виміряйте: запустіть date -Is та timedatectl у WSL2. Підтвердіть, чи це дрейф, чи часовий пояс.
Підтвердіть службу синхронізації: якщо є systemd — перевірте systemctl status systemd-timesyncd (або chrony, якщо встановлений).
Виправте базові речі: увімкніть демона (timesyncd або chrony), вкажіть погоджені джерела часу, перевірте зсув.
Обробіть сон: якщо зсув з’являється після відновлення — реалізуйте детермінований крок: рестарт служби часу або, якщо потрібно, рестарт WSL — тригерний після пробудження.
Верифікуйте тестом помилки: повторіть перевірку дійсності TLS і оновлення репозиторію. Не оголошуйте перемогу, поки початковий симптом не зникне.

Якщо взяти одну упереджену пораду: ставтеся до часу як до інфраструктури, навіть на ноутбуці. Особливо на ноутбуці. Ваші інструменти зараз — розподілені системи в худі.