[SailfishDevel] Warning: File `Makefile' has modification time 0.51 s in the future

[christopher.lamb at thurweb.ch]

Hi David

As we are in danger of taking this thread in a direction that the OP  
CDW probably did not intend I'll keep it short(ish) ....8-)

You are right that NTP is very tricky when VMs are involved. VMs need  
exactly the right NTP config to work properly (e.g. to jump the time  
quickly after a suspend).

The ultimate crime is to run an NTPD Server in a VM. The less said  
about that the better.

For those in the need of some nerdy bedtime reading there is an  
excellent document on the topic from VMWare:

http://www.vmware.com/files/pdf/Timekeeping-In-VirtualMachines.pdf

While it specific for VMWare, much of the content is relevant to other  
virtualisers (e.g. VirtualBox)

Cheers

Chris



Zitat von "David Greaves" <david.greaves at jolla.com>:

> On 15/04/14 07:07, christopher.lamb at thurweb.ch wrote:
>> Hi Thomas
>>
>> Earlier this year in addition to my normal day job I took over  
>> responsibility
>> for a server farm of over 50 servers both real and virtual. Their  
>> clocks, system
>> and hardware were all over the place. This lead to strange knock on effects,
>> like Samba not being able to authenticate users via SSSD / LDAP.
>>
>> In order to git the clocks under control again I was forced to find out much
>> more about clock-skew {1} and NTP then I cared for. As a result I  
>> can be very
>> boring on the subject. 8-)
>>
>> While ntpdate is a valid pragmatic workaround, it remains a workaround, as a
>> properly configured ntp daemon should automatically keep your  
>> system clock in
>> sub millisecond sync. Be aware also that NTDATE is deprecated {2}.  
>> Instead you
>> should use ntpd -gq
>
> Personally I think you should use a virtualisation specific solution to time
> sync if possible - it tends to cope better with virt specific issues like
> suspend and migrate. eg VMs running on laptops. In this case the VM  
> may not even
> know that it was suspended since the virt layer does it, not VM pm layer and
> hence cannot trigger special-case timesync handling.
>
> Running ntp on all guests is required in some situations though (eg  
> older xen).
>
> Happy to hear any counter-arguments though
>
> nb - in farm situations this also means that you simply run ntp on  
> the physical
> hosts and that's one less config pita on the guests :)
>
>> However if the time is already "too far off" the NTD may never be  
>> able to catch
>> up (as normally it only makes small jumps {3), or even give up altogether.
>>
>> When I encountered a server with clock(s) "way off" I used the set  
>> of commands
>> below to get it back in line.
>>
>> hwclock --show
>> date
>> service ntpd stop
>> ntpd -gq
>> hwclock --systohc --localtime
>> service ntpd start
>> hwclock --show
>> date
>>
>> After that, if NTPD is properly configured, then NTP should be able  
>> to keep the
>> server's system clock in line.
>>
>> HtH
>>
>> Chris
>>
>>
>> {1} the root of all evil
>> {2} http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate
>> {3} by my measurements about 1.7 mins per day
>>
>>
>> Zitat von "Thomas Tanghus" <thomas at tanghus.net>:
>>
>>> On Monday 14 April 2014 14:49 Chris Walker wrote:
>>>> I installed the ntp client and it now picks up network time. I'm
>>>> assuming therefore that there is some time 'slip' between the host
>>>> machine and VBox.
>>>
>>> I had the same problem and now run ntpdate from cron.daily. Turns  
>>> out my PCs
>>> clock loses ~5 seconds(sic!) for every 24h :(
>>>
>>> --
>>> Med venlig hilsen / Best Regards
>>>
>>> Thomas Tanghus
>>> _______________________________________________
>>> SailfishOS.org Devel mailing list
>>>
>>
>>
>>
>> _______________________________________________
>> SailfishOS.org Devel mailing list
>
> _______________________________________________
> SailfishOS.org Devel mailing list
>