Closed Bug 415798 Opened 17 years ago Closed 17 years ago

check linux build VMs for incorrect clock

Categories

(Release Engineering :: General, defect, P1)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: bhearsum, Assigned: bhearsum)

Details

Some of the try server and release automation slaves' clocks were off by an hour. We should check the rest of our machines and make sure they are OK. It's an easy fix: 1) set date properly 2) hwclock --hctosys I did a quick survey of release automation machines and out of them only staging-1.8-master is out of sync. I haven't looked at other machines.
Priority: -- → P3
Can you please explicitly confirm this is fixed for all of our linuxVMs, including rechecking the VMs that you did before, to make sure the fix is holding? Also, it might be good to check the ref image VMs that we use as basis for cloning new VMs. I'm concerned that we're about to create a bunch of VMs for Moz2, mobile and more try slaves - and I really dont want to propagate this lossage even wider.
I just had a look at the Linux ref platform image and it appears to be out of sync.
Assignee: nobody → bhearsum
Priority: P3 → P1
The ref platform VM should be synced up now. I ran the following to do it: date +%T --set=14:01:00 hwclock --systohc The 'scrubbed' version of the ref platform VM (the one used for public releases of it) has also been fixed in the same way. As for the rest of them, the following needing the time fixed: staging-1.8-master try2-linux-slave moz2-linux-slave1 staging-try-master The rest of them (listed below) had the correct time: argo argo-vm balsa18-branch production-1.8-master crazyhorse fxdbug-linux-tbox fx-linux-tbox fx-linux-1.9-slave1 fx-linux-1.9-slave2 karma l10n-linux-tbox moz180-linux-tbox prometheus-vm staging-prometheus-vm staging-1.9-master production-prometheus-vm production-1.9-master tb-linux-tbox try1-linux-slave moz2-master xr-linux-tbox As best I can remember, all of the slaves that needed fixing were cloned after daylight savings time ended. My suspicion is that because the reference platform VM is shut off it never came out of daylight savings time properly. I don't have evidence to support this other than that stated above. It may be hard/impossible to test this theory until we enter daylight savings again :(. In any case, this is fixed.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Very very cool, thank you Ben. This was really disruptive to us today, so nailing this quickly & thoroughly like you just did was important. Thanks!
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.