Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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...

share|improve this question
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. – gtirloni Nov 4 '10 at 0:53

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

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
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 – Matthew Savage Nov 6 '10 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.

share|improve this answer
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. – Matthew Savage Nov 4 '10 at 3:10
@Matthew - Oh well! – Mark Henderson Nov 4 '10 at 3:34
Thanks anyways - damn timezone logic getting in the way of things! – Matthew Savage Nov 6 '10 at 1:32

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.