3

I've seen a bunch of these questions, most notable this one, which all say pretty much the same thing: This error is caused by the modification time of the source files being in the future, which usually occurs on a mounted NFS when the server clock and client clock are not in sync.

I've tried to touch all the files in my directory, as many have suggested. when that didn't work, I actually attempted copying all files out of the mounted drive and into a local drive, touching them again, then rerunning the build, and I still get the same error. Is there any other way to solve this problem?

Community
  • 1
  • 1
ewok
  • 20,148
  • 51
  • 149
  • 254
  • 1
    This question probably belongs at http://unix.stackexchange.com/ or http://serverfault.com, but the solution would be to sync your client machine (or your server) to NTP and ensure their clocks are in sync. – Ryan J Dec 10 '14 at 17:32
  • as I said, I've copied the files off the mounted drive so they are stored locally on the build machine. The files I am referencing in the build have no connection to the server. – ewok Dec 10 '14 at 17:37
  • have you verified that the modification time actually updates to match the proper system time when you `touch`? Even though, that's a hack solution. Your clocks should be sync'd properly. Sometimes extreme drift can be a sign your crystal may be going south because it can't keep time. – Ryan J Dec 10 '14 at 17:40
  • I did a little more digging. The problem I was having with trying to reset the clock by hand was that I was changing the hwclock, not the system clock. I can't seem to get my machines through the proxy to an ntp server, but for now they are close enough – ewok Dec 10 '14 at 18:32
  • 1
    possible duplicate of [Compiling C++ on remote Linux machine - "clock skew detected" warning](http://stackoverflow.com/questions/3824500/compiling-c-on-remote-linux-machine-clock-skew-detected-warning) – Thijser Jan 07 '15 at 09:24
  • The suggestion to sync the systems with NTP doesn't work well - the builds are sensitive to clock skew on the order of milliseconds. I found that the clocks de-sync to intolerable levels within minutes of NTP sync-ing. – user515655 Apr 23 '19 at 01:34

2 Answers2

2

The NFS server and NFS client's system times are out of sync. The NFS server is probably drifting ahead.

Running make on an NFS mount is sensitive to the millisecond level so client/server system times must be tight as a drum. This can be done by having your NFS client(s) sync their time off of the NFS server's time using NTP at the highest rate allowed (usually 8 seconds). On a LAN this should get you sub-millisecond accuracy.

  • Install NTP on both the NFS client(s) and the NFS server.
  • On the NTP config file of the clients (ntp.conf in linux), comment out the entries starting with 'pool' or 'server' and add the line:

server [put address of the nfs server here] minpoll 3 maxpoll 3

... The '3' is a power-of-two in seconds for the polling interval, hence 8 seconds. The NFS server's NTP config file can probably be left alone.

  • Restart the ntpd service on your client.
  • Test that your client is syncing by using the linux command within the client:

ntpq -p

... the important part is that your 'reach' column is not zero for long as that means it cannot contact the server's NTP.

  • If they don't sync, you may have to reboot the client and server. This may be the case with Synology NAS as the NTP server.

  • Perform a full clean of your build (even nuke the directory and re-clone if convenient) and try again.

Similar answers are throughout the internet, but they suggest simply installing NTP to the machines. This wasn't good enough to solve the issue for me - they weren't synced tightly enough. A better way is to sync the clients' clocks to the server's clock on the local network at very frequent intervals. This is frowned upon with the internet but cheap on a LAN.

If this isn't possible, at least try to ensure NTP on the clients and server uses the same time servers in its pool/server entries.

user515655
  • 989
  • 2
  • 10
  • 24
1

If you are using Windows check if you compiling on a FAT file-system and if so try to switch.

FAT has a 2 second resolution, so its possible for your build to add to an archive, compile the next file, but detect that the archive is already up to date. Time resolutions for other file systems are listed in another answer.

If you must FAT consider the .LOW_RESOLUTION_TIME special target.

Jarve1024
  • 11
  • 1