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, [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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
> >
--~--~---------~--~----~------------~-------~--~----~
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/capistrano
-~----------~----~----~----~------~----~------~--~---
