I need to set the time on an Ubuntu Server forward 1 week, and keep it there (this is for a testing environment with date-specific conditions which need to be tested/verified by the stakeholders), however when I do this (with date -s 2010-11-11T00:00:00) the time resets back to the 'real' value after about 30 minutes.

I have disabled NTP, ntpdate etc, even removed the NTP packages, disabled munin-node for monitoring et-al, but it still happens and I can't seem to figure out what is happening.

I tried setting up a script to keep the time shifted forward every minute bit it causes weird behavior/issues with Nginx and Varnish when it switches back and forward between the script runs.

Any advice?

(Sidenote: this is an Ubuntu 9.10, running on EC2)

Additional Info: There are no cron jobs running relating to time, and I am unable to access the hardware clock to try and push that forward and use that as the source....

I am kind of thinking that this is one of the idioms of EC2 - you get a 'really reliable' clock, regardless of what you do...

  • Try to look for messages in /var/log that are related to time. Do you have custom scripts doing things? grep them all for date/ntpdate/etc.
    – anon
    Nov 4, 2010 at 0:53

4 Answers 4


Is it possible that any virtual machine guest additions on EC2 are performing time sync with the host independent of NTP?


If there are only a few processes that you need to lie to you could use libfaketime:

libfaketime intercepts various system calls which programs use to retrieve the current date and time. It can then report faked dates and times (as specified by you, the user) to these programs. This means you can modify the system time a program sees without having to change the time system-wide.


Check out /etc/cron.d and /etc/cron.hourly, you should find something there. grep for ntpdate and/or hwclock.

If you already removed the ntp package, then it is likely to be the hardware clock (hwclock) being synchronized.

  • Unfortunately it seems that I can't access the hwclock - I was thinking that perhaps the host of the VMs is updating the hardware clock. Problem is that I can't see /dev/rtc* anywhere and hwclock raises errors about that Nov 6, 2010 at 1:33

A simple fix might be to set your timezone to one hour ahead of where you are now (+10 to +11, or -8 to -7 for example)? That way, the next time your clock syncs it will still have the "wrong" time.

  • The times in our application are using time zones already, which in the end is converted back to UTC, so setting the timezone forward won't help in this instance. Nov 4, 2010 at 3:10
  • @Matthew - Oh well! Nov 4, 2010 at 3:34
  • Thanks anyways - damn timezone logic getting in the way of things! Nov 6, 2010 at 1:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .