Fixing clock skew problems in GNU/Linux

I ran into a bit of trouble recently on my new Gentoo GNU/Linux laptop because I accidentally set the date a whole month in the future, and then proceeded to install lots of packages before realizing my mistake. I corrected the date, but then I was left with a slew of clock skew problems. The problems occur during boot init scripts, which complain that configuration files were created or modified in the future. This is little more than an annoyance, but the clock skew most definitely did mess up my attempted installation of VMware. Make uses files’ modified times to determine if they should be recompiled; obviously, any file seeming to date from the future won’t be recompiled. This will affect package managers like portage or apt-get.

The simplest solution would be to wait out the extra time of the skew so that it doesn’t appear that files were created in the future. This is okay when you’re dealing with broken timezone settings, which can’t make the files appear to be from more than a day in the future, but it’s not good for dealing with skews of a month. I simply can’t wait that long to install new software. So I came up with a better solution. This fix should work for any GNU/Linux system:

(as root)

$ cd /
$ touch currtime
$ find . -cnewer /currtime -exec touch {} \;

The first two steps involve going to the root of the filesystem and creating a dummy file called currtime. This file is used solely for its timestamp, which will effectively represent the present. Any file with a modified time after currtime appears to be modified in the future, which the third line then corrects. The program find has a bunch of parameters that can be used to specify how recent a file is (e.g. “modified within last X hours”), but they can’t seem to take a negative number as a parameter (which would indicate modification in the future) because the negative sign is interpreted as a parameter signal. Hence why I’m bothering with the dummy file currtime; it’s simply easiest to do the time calculations by comparing modified times between files.

One last thing to explain: the program touch has two separate functionalities. If called with a filename that doesn’t yet exist, it will create that file will null contents, which is what we use to create currtime. And if the file does exist, it will “touch” the file, meaning that the modified time is updated to the present but no changes are made to the actual contents of the file. So the full script works like this: make a dummy file, search the entire filesystem for anything that appears to have been modified more recently than the dummy file, and touch all these files to make them appear to have been modified in the present.

You will get some errors from non-touchable parts of your system, like devices, pseudo files in /proc, etc. Don’t worry about them. Their modified times can’t be set, so you won’t do any harm, and they don’t need any fixing. The last thing to do is to cleanup your root directory by removing the dummy file currtime. And that’s it — the clock skew is totally corrected.

3 Responses to “Fixing clock skew problems in GNU/Linux”

  1. Nick Says:

    Wow, thanks, this solution is simple and ideally fit my situation!

  2. Cyde Weys Says:

    Glad it helped someone! That’s why I put it online after I spent the time figuring it out myself. May I ask how you found this? Google?

  3. Andres101 Says:

    I found this via google search terms: touch files modified in future

Feel free to leave a comment: