System clock tampering detected. License checkout will fail


I’ve used MBed about a year ago and it was on a different laptop. I have since got a new one but this system clock error keeps coming up during builds.

Right now my workaround is to keep hitting build until it finishes and then it will let me program to a device but it will still happen from time to time and sometimes takes longer to build so it’s still an issue.

Does anyone have any suggestions?

Hi @Anthony_Roberts ,

Have you checked that your system clock is indeed set correctly?
Please also make sure you’re using the latest version of Mbed Studio (v1.4.4).

Carey - Studio Team

Using the Mbed Studio v1.4.4 on Fedora 36 and it is a new install and get the same error as Anthony. System clock is set properly and timeanddatectl has RTC set to UTC not Local.

Yes the clock is correct and it is the latest version.
Repeatedly hitting build will successfully build the program but the error is still there nonetheless.

Hi,

You can find some information here:

https://developer.arm.com/documentation/ka002182/1-0

To detect future timestump files, try this…

# check future files
$ find . -type f -mmin -0 -exec ls -la {} \;
# and fix them
$ find . -type f -mmin -0 -exec touch {} \;

Also, according to here, FLEXLM v6+ checks /etc, /tmp and /var directories for UNIX. So, you can try:

$ sudo find /etc -type f -mmin -0 -exec ls -la {} \;
$ sudo find /etc -type f -mmin -0 -exec touch {} \;
$ sudo find /tmp -type f -mmin -0 -exec ls -la {} \;
$ sudo find /tmp -type f -mmin -0 -exec touch {} \;
$ sudo find /var -type f -mmin -0 -exec ls -la {} \;
$ sudo find /var -type f -mmin -0 -exec touch {} \;

Thanks,
Toyo

Indeed, as @MACRUM suggests, it’s worth checking for any erroneous file dates.

Just tried it again this morning. I checked for future files and there were none. When I loaded Mbed Studio, and then compiled and loaded the mbed-os-example-blinky, there were no errors and is working fine. I hate when this happens. There must have been one file that was out of sync and then today is past that date.

Well, should have not been so excited. Today there are no files out of sync and i get the dreaded “[ERROR] armclang: error: System clock tampering detected. License checkout will fail.” This is very frustrating and not much information from the system.

So, a couple of new things I found. If I run the build again after getting the error, it will pick up where it left off previously. I keep running the build and then it finally completes. I am thinking there is a timing issue in the file creation of the build that causes it to determine there is a future time stamped file. I am running this on a Fedora 36 system on an AMD Ryzen 9 5590. It compiles very fast.

So, I put mbed studio on my older Intel i5 system and it compiles much slower and no issues for the same build.

So my theory is there is a race condition on checking timestamps of files as it compiles. just my 2 cents.