Clock skew issue on Windows

[CalebDepatie]

Describe the bug Attempting to build with Meson on my windows machine (Meson installed from the MSI) produces a clock skew error with the file meson-private/coredata.dat however this issue does not get reproduced when I build on WSL (Meson installed through the package manager). I've attempted to correct the clock skew error through every method I know of but this has resulted in no change.

To Reproduce I've been using a simple build file just to get started.

project('beep', 'cpp', 
    default_options : ['cpp_std=c++17'],
    license : 'MIT')

executable('beep','test.cpp')

Expected behavior No Clock skew

system parameters

• Native build
• Windows 10
• Python 3.6.4
• Meson 0.54.2
• Ninja 1.10.0

[scivision]

Could you post the traceback (error messages)? What compiler is this with (different Meson code is invoked based on compiler)?

[CalebDepatie]

It's using the MinGW compiler. From the log:

Compiler stderr:

None of 'STRIP' are defined in the environment, not changing global flags.

ERROR: Clock skew detected. File S:\test\build\meson-private/coredata.dat has a time stamp 0.0308s in the future.

[kwende]

@CalebDepatie did you resolve this? I'm encountering it too.

[CalebDepatie]

@CalebDepatie did you resolve this? I'm encountering it too.

I dual boot, so I've just ended up using linux instead of windows.

However I did find out it that although its mentioning meson generated files as the issue, it's more likely that Ninja is the culprit here. I've read that it's particularly susceptible to clock skew issues. Unsure of how it would be fixed, I couldn't figure out a workaround as meson seems to remake the problem file each time the configuration fails, leading to the exact same issue.

[jwtowner]

Just found a workaround for this issue and it is to run $ sudo ntpdate time.windows.com periodically via your crontab and/or at the start of your build.

See these for more information: https://github.com/microsoft/WSL/issues/4245 https://github.com/microsoft/WSL/issues/5324

[han190]

I encountered the same issue using Meson and my problem appears when I changed the "data & time setting" under Windows 10. Since my project isn't too big I just redownloaded my repo and rebuild it with meson and the error message disappears.

[OscBacon]

Hey @jwtowner and all, since the previous issues got closed: I realized after suggesting using a cron job, that the cron job wasn't working. So while we wait for the official fix, this is what I'd done to make it work.

I added an entry to the root crontab (sudo crontab -e): * * * * * /usr/sbin/ntpdate time.windows.com Optionally, to get the update logged, I added a stdout + stderr print to a file: * * * * * /usr/sbin/ntpdate time.windows.com 2>&1 > ~yourusername/cron.out Note: it seems that only using a full path to ntpdate does the job

Lastly, the cron service is not started by default. Here's the combo that worked for me:

• Starting the service in the root bashrc: sudo echo "service cron start" >> /root/.bashrc
• Adding a task in the Windows Task Scheduler to start the cron service on login: https://askubuntu.com/questions/1165969/ubuntu-18-04-on-wsl-cron-daemon-not-running-after-reboot (tldr: add the following action: wsl.exe -u root service cron start)

[fermian]

I'm able to reproduce this problem when running a meson build in a non system drive (a FAT-32 formatted D:\ drive). The problem goes away when I build it in the C:\ drive (NTFS formatted). Maybe this bug is related to the file system?

I'm building on Windows directly, no WSL or Cygwin if that helps.

[sandy-lcq]

I am able to reproduce this on Linux system.

[Cartman0]

i have same issue on Debian on Windows10 Docker Desktop + VSCode. when meson setup:

vscode ➜ /workspaces/hello_c $ meson setup build_c/build build_c
The Meson build system
Version: 0.61.2
Source dir: /workspaces/hello_c/build_c
Build dir: /workspaces/hello_c/build_c/build
Build type: native build
Project name: c2exe
Project version: undefined
C compiler for the host machine: cc (gcc 10.2.1 "cc (Debian 10.2.1-6) 10.2.1 20210110")
C linker for the host machine: cc ld.bfd 2.35.2
Host machine cpu family: x86_64
Host machine cpu: x86_64
Build targets in project: 1

ERROR: Clock skew detected. File /workspaces/hello_c/build_c/build/meson-private/coredata.dat has a time stamp 0.4704s in the future.

meson ver:

vscode ➜ /workspaces/hello_c $ meson -v
0.61.2

[Cartman0]

I may solve it. maybe https://github.com/microsoft/WSL/issues/5324

wsl --update

then restart pc.

[afud]

I am able to reproduce this on Linux system.

I reproduced this issue on Linux system too, did you resolve it ?

[afud]

I update the interval time to avoid this issue, because on my system, skew is under 0.3s. Will this trigger other issues?

[Cartman0]

@afud HardWare clock is correct?

[Matthieu-Sauer]

fixed it on windows 11 with this tutorial:

https://techgenix.com/windows-server-time-clock-skew/

edit:

works on my ssd (C:) but not on my HDD (D:). Might have something to do with slow hdd?

[davihart]

Encountering this issue in linux using an NFS mounted drive. The workaround is to modify the check_clock_skew() function above but could a meson configuration knob be added to override the default delta value instead of modifying the function? Addressing the entire skew issue may sometimes be outside the control of the user (e.g. not an admin on all the devices in play).

I will open a new issue since this one mentions Windows explicitly.

[eli-schwartz]

The reason clock skew is a problem is because it can result in infinite reconfigure loops. Allowing infinite reconfigure loops seems bad.

[davihart]

The reason clock skew is a problem is because it can result in infinite reconfigure loops. Allowing infinite reconfigure loops seems bad.

The tolerance in the function above has likely been chosen while solving the issue for a specific scenario; however, it does not cover all situations. In the many runs where I see this (and sometimes the build just gets stuck until you work around it) the reported skew is always below < 0.01:

• .0021s
• .0072s
• .0034s

I've worked around the issue by modifying the meson supplied function with 0.01 but of course whenever this file gets updated I'll have to update it again. A cleaner solution seems to allow the user to override the value with perhaps a range limited value if "reconfigure loops" are a concern.

[eli-schwartz]

Then I would say that discussing the best tolerance value for reliably detecting "real" clock skew is a very reasonable discussion to have, independent of whether users should be controlling the value or disabling it altogether. I'm not sure what details went into determining the current value -- maybe it should be (unconditionally) changed.

[davihart]

I generally try to keep things simple because more s/w usually just invites more maintenance cost so suggested the 'config knob'. But, it seems that the s/w should tolerate/accommodate different environments via more sophisticated s/w or handing the problem over to the user to handle with a "guideline" and default behavior.

[Zylann]

I very often get this when I try to setup a build directory. This is on Windows 10, and my project is on an external SSD (file system is exFAT). I often have to retry dozens of times until it works.

[karelrooted]

when building on macOS(14.0) with a NFS mount directory (Unraid OS, the directory's hard disk is intel ssd 535 series 120gb ), encounter the same problem, Mac has configure ntp time server to the Unraid OS.

FYI: fix the problem after setting using ntp to No on the Unraid server

[ebosseck]

I also observed this issue on windows 10 with a build directory on an exfat formatted ssd. Once the ssd was formatted to NTFS, the error seems to have disappeared.

Meson: v1.4.0 Python: 3.10.11 OS: Windows 10 Pro 22H2

Tested both with builtin Mingw toolchain of CLion 2023.03.04 & Visual Studio Built Tools 2022 (both in combination with CLion as IDE)