Re: Time Sync and the local machine

This is a reference to the problem on VMware. 
http://www.excalibur-partners.com/archives/2

I first saw the problem on Microsoft's Virtual Server, where the same  
fix works.

On Dec 26, 2007, at 6:15 AM, mike-uc6gurhRjCpx3z9c7Zyw2w@xxxxxxxxxxxxxxxx wrote:

>
> Are you referring to VMware? Got a URL for the fix?
>
> My understanding is that Xen virtual hosts use the clock from the Dom0
> which is running ntp.
>
> I stopped using Parallels a while ago so can't comment (I like it but
> VMware Fusion won me over).
>
> - Mike
>
> On Dec 26, 3:38 pm, Peter Booth 
> <pbo...-ufkYR41HT3E7ORGMCZC4/9BPR1lH4CV8@xxxxxxxxxxxxxxxx> wrote:
>> It isn't as straightforward as it sounds. A Linux virtual machine
>> behaves differently to a Linux host wrt time-keeping. Linux kernel  
>> has
>> a number of alternate algorithms that can be used to adjust times.  
>> The
>> default algorith, when used in a VM, will cause the clock to advance
>> 60 seconds in about 48 real seconds, then be reset 12 seconds. In
>> other words "time goes backwards." The solution to this is to apply  
>> an
>> argument at boot time so that an alternate time adjustment algorithm
>> is used.
>>
>> This has nothing to do with NTP.
>>
>> On Dec 23, 2007, at 11:12 PM, m...-uc6gurhRjCpx3z9c7Zyw2w@xxxxxxxxxxxxxxxx 
>> wrote:
>>
>>
>>
>>> The release is based on a timestamp. That timestamp should refer to
>>> the time it was created or else it's misleading.
>>
>>> Your solution is great and I would support it if we didn't already
>>> have an easy, free way to keep computer times in sync (to within
>>> fractions of a second!). Incorrect clocks will affect more than
>>> Capistrano and it's best to fix broken windows.
>>
>>> People should ensure the clocks on their system are set correctly.  
>>> We
>>> solved the problem of keeping computers in sync a long time ago with
>>> ntp. My Mac came with it installed and configured out of the box.
>>
>>> - Mike
>>
>>> On Dec 24, 3:32 am, Mark Percival 
>>> <m...-t488x0r8fZES+FvcfC7Uqw@xxxxxxxxxxxxxxxx> wrote:
>>>> I came across this issue a couple days ago and found it  
>>>> interesting.
>>>> Quick rundown - I develop on a Ubuntu VM inside of my windows  
>>>> laptop.
>>>> This allows me to develop on a machine configured identically to my
>>>> production Ubuntu server. The problem is that sometimes the time  
>>>> gets
>>>> out of sync when I suspend the machine. So in some cases my Ubuntu
>>>> machine can think it's 3 days ago, especially if I suspend over the
>>>> weekend.
>>
>>>> Of course as Capistrano currently uses the date on the local  
>>>> machine,
>>>> you can wind up with a release directory that's actually behind
>>>> another deployment from another developer.
>>
>>>> For example -
>>>> The current date is midnight 12/20/2007, and my laptop thinks it's
>>>> 12/15/2007
>>>> /u/apps/sampleapp/releases/20071215000000 is where mine deployed
>>>> /u/apps/sampleapp/releases/20071217000000 is where another  
>>>> developer
>>>> deployed 3 days ago
>>
>>>> The "current" directory gets symlinked to the "20071215" directory
>>>> with the up to date code, and if you run a migration it gets run on
>>>> the latest directory, which in this case is set to the "20071217"
>>>> directory. So now you have your mongrels running off the "20071215"
>>>> directory, and the database still lacking the most recent update.
>>
>>>> Now obviously one solution is for me to sync my clock. I recognize
>>>> that it's ridiculous to expect capistrano to make up for my poor
>>>> "time
>>>> management"
>>
>>>> But I think there's a more subtle problem here. If you're working  
>>>> in
>>>> group where multiple people can deploy, you could still run into  
>>>> this
>>>> issue. For example, it's not absurd to expect a one developers  
>>>> clock
>>>> to be off my 5 minutes, and I've been in a situation where one  
>>>> person
>>>> has deployed and minutes later I fixed an issue and redeployed.
>>
>>>> I think the best solution is to base all release directory  
>>>> timestamps
>>>> off of the server. That completely solves the issue and to be  
>>>> honest
>>>> it just make more sense to organize around one time standard,  
>>>> rather
>>>> than to expect everyone to be perfectly in sync.
>>
>>>> I propose the following modification -
>>>> _cset(:release_name)
>>>> { Time.parse(capture('date')).utc.strftime("%Y%m
>>>> %d%H%M%S") }
>>
>>>> This has solved the problem entirely for me, and now I can happily
>>>> update from a laptop that think it's Dec 15, 1986, as I often do
>>>> whilst traveling around in my DeLorean.
>>
>>>> Of course I'm not an expert on Capistrano, so I'd appreciate any
>>>> thoughts on why this would be a good or bad change.
>>
>>>> Thanks,
>>>> Mark Percival
> >