192

I'm connected to my university's small Linux cluster via PuTTY and WinSCP, transferring files using the latter and compiling and running them with the former. My work so far has been performed in the university's labs, but today I have been doing some work at home that generated an interesting warning.

I uploaded an entire folder of stuff and, upon running the make command, I get this as the last line of output:

make: warning: Clock skew detected. Your build may be incomplete.

The resulting binary works correctly, and there doesn't seem to be any other unexpected errors in the build process.

I seem to be able to trigger the error by building after uploading some new / replacement files (I edit everything locally then upload the new version), so I'm wondering if it's something just as simple as mismatched file modification times? Or something more concerning?

So, should I be worried? How do I fix/prevent this?

alk
  • 69,737
  • 10
  • 105
  • 255
DMA57361
  • 3,600
  • 3
  • 27
  • 36
  • Clock differences are a possibility, as mentioned in some of the answers. You could also compare the modification times of the source files before and after copying - you might find that they're an hour different due to the two OSes/filesystems treating daylight savings differently. – Steve Jessop Sep 29 '10 at 18:10
  • One last suggestion: I don't have any Windows machines so I'm not familiar with the capabilities of PuTTY and WinSCP, but often file transfer tools have options that allow you to control whether the modified time is preserved or not. Your mod times are obviously preserved, but if you can turn that off then when the files are copied to your system they will use mod times set by your system clock, not the remote system clock. – MadScientist Aug 02 '12 at 02:12

14 Answers14

254

That message is usually an indication that some of your files have modification times later than the current system time. Since make decides which files to compile when performing an incremental build by checking if a source files has been modified more recently than its object file, this situation can cause unnecessary files to be built, or worse, necessary files to not be built.

However, if you are building from scratch (not doing an incremental build) you can likely ignore this warning without consequence.

Tyler McHenry
  • 74,820
  • 18
  • 121
  • 166
  • 4
    It seems the cluster has a time ~3mins *behind* my desktop, so files having been modified in the "future" seems a likely cause. Is the safest bet then to wait 5mins or so after uploading anything before running a build? I'd rather not have to wait, so is there some way to reset the times on any uploaded "future" files to avoid the issue? – DMA57361 Sep 29 '10 at 18:27
  • 23
    @DMA57361: `touch *` will update the mtimes to the current time. Alternatively you can enable NTP on your desktop to synch your clock (assuming it's your desktop that's wrong, and not the Uni's machine... if the latter, maybe ask the sysadmins to fix it?) – caf Sep 30 '10 at 05:58
  • 2
    Thanks for that, `touch *` it is for now, and I'll see if I can find out which is wrong and maybe have a word with the admin guy next time I'm on site. – DMA57361 Sep 30 '10 at 07:30
  • 2
    I needed a recursive touch in my case: `find . -exec touch {} \;` – Aaron Swan May 18 '17 at 14:42
  • 11
    @AaronS for commands like `touch` that can accept multiple files to act on, you can do it (much) more efficiently with `find . -exec touch {} +` which will invoke `touch` with as many arguments as possible. – Viktor Dahl Jul 06 '17 at 23:34
  • I had this problem in a virtual machine's (Ubuntu) shared folder with the host (MacOS). I fixed it by setting Ubuntu's time zone to automatically sync, then used the `touch *` comment above. – Rico Picone Apr 07 '20 at 00:05
65

Typically this occurs when building in a NFS mounted directory, and the clocks on the client and the NFS server are out of sync.

The solution is to run an NTP client on both the NFS server and all clients.

janneb
  • 36,249
  • 2
  • 81
  • 97
  • 1
    I am not building on any NFS mounted dir. – RajSanpui Sep 28 '11 at 10:56
  • LEt me know if you can give some tips to supress such warning, as it really does not make any difference in the execution or the results. – RajSanpui Sep 28 '11 at 11:05
  • @kingsmasher1: Run an NTP client on all machines involved. – janneb Sep 28 '11 at 11:05
  • I just checked my target. The date isn't set. I am not sure how to run NTP here. Is it okay, if i update the date? My x86 where i build is set to current date, but my target (where i execute) has a date of soem 1970's. – RajSanpui Sep 28 '11 at 11:20
  • 1
    The problem is sorted. I changed my target date to current date and the warning vanished. So the problem is: If target date is a back date than the executable date, the problem happens. – RajSanpui Sep 28 '11 at 11:28
  • For everybody's convenience: Target = platform where i am executing. In my case my target is different than the host where i compiled the files using a cross compiler. – RajSanpui Sep 28 '11 at 11:50
36

Install the Network Time Protocol

This also happened to me when running make on a Samba SMB CIFS share on a server. A durable solution consists in installing the ntp daemon on both the server and the client. (Please, note that this problem is not solved by running ntpdate. This would resolve the time difference only temporarily, but not in the future.)

For Ubuntu and Debian-derived systems, simply type the following line at the command line:

$ sudo apt install ntp

Moreover, one will still need to issue the command touch * once (and only once) in the affected directory to correct the file modification times once and for all.

$ touch *

For more information about the differences between ntp and ntpdate, please refer to:

Community
  • 1
  • 1
Serge Stroobandt
  • 28,495
  • 9
  • 107
  • 102
15

Simple solution:

# touch filename

will do all OK.

For more info: http://embeddedbuzz.blogspot.in/2012/03/make-warning-clock-skew-detected-your.html

Flexo
  • 87,323
  • 22
  • 191
  • 272
Brijesh Valera
  • 1,085
  • 2
  • 9
  • 30
8

type in the terminal and it will solve the issue:

find . -type f | xargs -n 5 touch

make clean

clean
Khan
  • 1,288
  • 12
  • 11
7

The other answers here do a good job of explaining the issue, so I won't repeat that here. But there is one solution that can resolve it that isn't listed yet: simply run make clean, then rerun make.

Having make remove any already compiled files will prevent make from having any files to compare the timestamps of, resolving the warning.

skrrgwasme
  • 9,358
  • 11
  • 54
  • 84
  • this is not a real solution: if the compiler needs 30 min to compile everything and I am working on a single file (where the build need 2 sec only) I am going to waste all the day to make modification on a single part of a huge library. Right? However yes, with `make clean` you will solve the issues (by creating others). – Leos313 Dec 09 '19 at 08:34
  • @Leos313 I'm just sharing what worked for me. I encountered it on a school network that I didn't have root permissions on so I couldn't set up NTP, and I didn't trust the compilation results of just using `touch` on all the files. You're right that it will require a full recompilation, but whether or not that's worth the time will vary depending on your priorities and project size. I don't think it's accurate to say it's "not a real solution" just because it's not the best or has some drawbacks. It'll fix the problem; sounds like a solution to me. – skrrgwasme Dec 09 '19 at 09:01
  • I did not vote down :) it solves the problem by creating others. Nothing more than this! :) for sure the answer will help in most of the situation and it is worth to be here! What I want to underline and, sometimes, it is better to stay with the warning than running `make clean` – Leos313 Dec 09 '19 at 09:04
6

According to user m9dhatter on LinuxQuestions.org:

"make" uses the time stamp of the file to determine if the file it is trying to compile is old or new. if your clock is bonked, it may have problems compiling.

if you try to modify files at another machine with a clock time ahead by a few minutes and transfer them to your machine and then try to compile it may cough up a warning that says the file was modified from the future. clock may be skewed or something to that effect ( cant really remember ). you could just ls to the offending file and do this:

#touch <filename of offending file>

Rob Kennedy
  • 161,384
  • 21
  • 275
  • 467
z -
  • 7,130
  • 3
  • 40
  • 68
4

I have had this in the past - due to the clocks being out on the machines. Consider setting up NTP so that all machines have the same time.

Ed Heal
  • 59,252
  • 17
  • 87
  • 127
2

This is usually simply due to mismatching times between your host and client machines. You can try to synchronize the times on your machines using ntp.

Soo Wei Tan
  • 3,262
  • 2
  • 34
  • 36
1

The solution is to run an NTP client , just run the command as below

#ntpdate 172.16.12.100

172.16.12.100 is the ntp server

Andrew Barber
  • 39,603
  • 20
  • 94
  • 123
Surjit
  • 19
  • 1
  • 2
    Welcome to Stack Overflow! Thanks for your post! Please do not use signatures/taglines in your posts. Your user box counts as your signature, and you can use your profile to post any information about yourself you like. [FAQ on signatures/taglines](http://stackoverflow.com/faq#signatures) – Andrew Barber Feb 28 '13 at 06:17
  • Using `ntpdate` is just a one off correction. It is better to install `ntp` on both the server and client to obtain a durable solution. – Serge Stroobandt Jan 26 '14 at 15:45
1

Replace the watch battery in your computer. I have seen this error message when the coin looking battery on the motherboard was in need of replacement.

BlushONine
  • 11
  • 1
1

(Just in case anyone lands here) If you have sudo rights one option is to synchronize the system time

sudo date -s "$(wget -qSO- --max-redirect=0 google.com 2>&1 | grep Date: | cut -d' ' -f5-8)Z"
ObviousChild
  • 119
  • 1
  • 9
-1

Make checks if the result of the compilation, e.g. somefile.o, is older than the source, e.g. somefile.c. The warning above means that something about the timestaps of the files is strange. Probably the system clocks of the University server differs from your clock and you e.g. push at 1 pm a file with modification date 2 pm. You can see the time at the console by typing date.

fschmitt
  • 3,478
  • 2
  • 22
  • 24
-4

This happened to me. It's because I ran make -j 4 and some jobs finished out of order. This warning should be expected when using the -j option.

kilojoules
  • 9,768
  • 18
  • 77
  • 149