On June 30th at precisely 23:59:59, the world’s atomic clocks will pause for a single second. Or, to be more precise, they’ll change to the uncharted time of 23:59:60 before ticking over to the more worldly hour of 00:00:00 on the morning of July 1st, 2015. This addition of a leap second, announced by the Paris Observatory this week, is being added to keep terrestrial clocks in step with the vagaries of astronomical time in this case, the slowing of the Earth’s rotation. Official reference from INTERNATIONAL EARTH ROTATION AND REFERENCE SYSTEMS SERVICE (IERS) http://datacenter.iers.org/web/guest/eop/-/somos/5Rgv/latest/16
Tested on vt14 3.5.1-0.1.el6ev (engine, dwh & reports) with no problem. It seems that everything is working normally. tested leap second: NTP: 3644697600 # 1 Jul 2015 rpm -qa | grep tzdata tzdata-2015a-1.el6.noarch tzdata-java-2015a-1.el6.noarch epoch time: 1435708798.000708540 1435708799.000893451 1435708799.001837884 1435708800.002010346 1435708801.002188317
Piotr, can you please take a look and check whether the exception described in comment #9 has anything to do with the leap ?
I can see plenty of: [org.ovirt.vdsm.jsonrpc.client.reactors.ReactorClient] (SSL Stomp Reactor) Connecting to /10.34.60.150 Which means that we had issues during connecting to the host for most of the time. Can you please provide vdsm logs.
Created attachment 1010190 [details] Engine and vdsm logs Because I reinstalled the host since then, I had to test it again. So providing new engine and vdsm logs.
I checked the logs and I am not able to correlate engine and vdsm logs. From the engine log perspective I can see that we keep connecting to the host. Prior to reconnection I can see following WARN: Message: Used CPU of host pmatyas-host03 [99%] exceeded defined threshold [95%] Can you please provide steps to reproduce or help me to correlate logs of both sides of the system?
On engine side, the script moved the time ahead of hosts. I restarted ntpd service now (time is synced) and testing it slowly, so I can check the logs tomorrow. But the engine is running in my opinion correctly, because I have a VM running there from start. But I'll wait till tomorrow with changing bug status. Steps to reproduce are running the script from comment 8 on engine with -s parameter, but not on host.
The logs are clean when I tested it now. Both with host 6.6 and 7.1.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2015-0888.html