http://bugs.winehq.org/show_bug.cgi?id=33788
Bug #: 33788 Summary: The VMs clock is off Product: Wine-Testbot Version: unspecified Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: unknown AssignedTo: wine-bugs@winehq.org ReportedBy: fgouget@codeweavers.com Classification: Unclassified
The issue is that WineTestBot restores running VM snapshots. So when these start their clock is still set to whenever the snapshot was taken which can be months ago. VMware had a special driver that took care of updating the VM clock automatically when starting the snapshot but QEmu/KVM does not.
The VMs may synchronize with an Internet clock eventually depending on thet particular Windows' default configuration and how often they do so.
This has an impact on some tests and causes failures. My understanding is that in particular the certificate tests check that some online certificates have expired. But obviously if the VM's clock is still running months behind it may not consider the certificate to have expired yet.
These tests should arguably compare the system clock with the certificate expiration date and realize that the certificate has not expired yet. However that's not the point of the test.
The solution is to force the VM clock to resynchronize by running a special command when we start the snapshot. These commands depend on the Windows version :-(
Windows >= 2003 w32tm /config /syncfromflags:manual /manualpeerlist:0.pool.ntp.org,1.pool.ntp.org,2.pool.ntp.org,3.pool.ntp.org
Windows XP net time /setsntp:"0.pool.ntp.org 1.pool.ntp.org 2.pool.ntp.org"
http://bugs.winehq.org/show_bug.cgi?id=33788
--- Comment #1 from François Gouget fgouget@codeweavers.com 2013-06-14 18:57:55 CDT --- The problem with the above commands is that on some VMs the 'Internet Time Synchronization' service is not running. For instance this is the case on the Windows 7 Ultimate VM. I'm pretty sure I did not explicitly make it so and also that it's running in some other VMs. I kind of like the variety though. But it does complicate the use of these commands.
Another approach would be to use cmd's basic "time HH:MM" and "date YYYY-MM-DD" commands. They won't let us set the clock with sub-second accuracy but I really don't think that matters. The advantages are that they work everywhere (I think), take effect instantly (I think the time synchronization commands sometimes skew the clock to resynchronize it), and don't depend on the time service to be running.
In all cases we should be doing the time synchronization in RevertVM.pl: send the appropriate command before the 30s sleep.
http://bugs.winehq.org/show_bug.cgi?id=33788
Jacek Caban jacek@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jacek@codeweavers.com
--- Comment #2 from Jacek Caban jacek@codeweavers.com --- This bug hits us again. Currently most of wininet and urlmon fail. winehq.org has a new certificate that can't be validated (because date on VMs predates certificate issue time).
http://bugs.winehq.org/show_bug.cgi?id=33788
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Assignee|wine-bugs@winehq.org |fgouget@codeweavers.com
http://bugs.winehq.org/show_bug.cgi?id=33788
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #3 from François Gouget fgouget@codeweavers.com --- I believe this got fixed by the following commit (I also updated the TestAgent server on all the WineTestBot VMs). Let me know if there are still problems.
commit df9f82b2f5e8040085f97e116f93f60187825ec7 Author: Francois Gouget fgouget@codeweavers.com Date: Thu Mar 6 15:24:05 2014 +0100
testbot/testagentd: Add an RPC to set the remote host's system time.
https://bugs.winehq.org/show_bug.cgi?id=33788
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #4 from Bruno Jesus 00cpxxx@gmail.com --- Closing other products fixed bugs.