Closed
Bug 415798
Opened 17 years ago
Closed 17 years ago
check linux build VMs for incorrect clock
Categories
(Release Engineering :: General, defect, P1)
Release Engineering
General
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.
Assignee | ||
Updated•17 years ago
|
Priority: -- → P3
Comment 1•17 years ago
|
||
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.
Assignee | ||
Comment 2•17 years ago
|
||
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
Assignee | ||
Comment 3•17 years ago
|
||
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
Comment 4•17 years ago
|
||
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!
Updated•12 years ago
|
Product: mozilla.org → Release Engineering
You need to log in
before you can comment on or make changes to this bug.
Description
•