Closed Bug 649641 Opened 15 years ago Closed 14 years ago

time on some linux slaves is incorrect

Categories

(Release Engineering :: General, defect, P2)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: dustin, Assigned: nthomas)

References

Details

(Whiteboard: [buildslaves])

Attachments

(2 files)

dustin@lorentz ~ $ ssh cltbld@linux64-ix-slave05 date && date Wed Apr 13 01:00:38 PDT 2011 Wed Apr 13 10:06:38 CDT 2011 CDT and PDT are not 9 hours apart :) Does this call for NTP? Or for setting the hardware clock?
I haven't checked any of the other linux64 builders - I just happened to notice on this one.
linux-ix-slaveNN too: [cltbld@linux-ix-slave08 slave]$ ssh -oBatchMode=no production-master01 date && date Wed Apr 13 08:29:14 PDT 2011 Wed Apr 13 09:26:34 PDT 2011 Should we be running NTP on the slaves?
Summary: time on linux64-ix-slave05 is incorrect → time on some linux slaves is incorrect
needs triage..
Assignee: dustin → nobody
Whiteboard: [buildslaves] → [buildslaves][triagefollowup]
(In reply to comment #2) > Should we be running NTP on the slaves? Yes. Cf bug 539278.
Whiteboard: [buildslaves][triagefollowup] → [buildslaves]
See Also: → 646056
Whiteboard: [buildslaves] → [buildslaves][triagefollowup]
Whiteboard: [buildslaves][triagefollowup] → [buildslaves]
Bugs which break clobber are more important than P4, it turns out.
Assignee: nobody → nrthomas
Priority: P4 → P2
*clobberer So the issue is that we should disable ntp on linux VMs, since the VMWare tools will fight with you otherwise, but we need to enable it on hardware (eg ix). Could someone who knows about puppet suggest how http://hg.mozilla.org/build/puppet-manifests/file/default/modules/ntp/manifests/init.pp#l15 might be adapted (or just grab the bug).
We can probably use the 'virtual' facter fact in a case statement. [cltbld@linux-ix-slave03 ~]$ facter virtual physical If I have a chance today, I'll grab this bug.
And indeed http://tbpl.allizom.org/php/getParsedLog.php?id=6037003&full=1 is linux-ix-slave42 failing to pick up an 11:40 clobber because "our last clobber date ... 15:28:28"
(In reply to John Ford [:jhford] from comment #10) > We can probably use the 'virtual' facter fact in a case statement. > > [cltbld@linux-ix-slave03 ~]$ facter virtual > physical Alas, no. [cltbld@moz2-linux-slave30 ~]$ facter virtual physical
Works for me, now: [root@moz2-linux-slave26 ~]# facter virtual vmware I just landed some patches to do this again in PuppetAgain: http://hg.mozilla.org/build/puppet/rev/294b5dae3921 http://hg.mozilla.org/build/puppet/rev/7410d33d3ec0 if you want to try to abstract any of that into the existing puppet-manifests
Turns out that facter is wrong when not run as root. This is an untested patch to do the right thing on VMs and real hardware.
Comment on attachment 579909 [details] [diff] [review] [puppet-manifests] Nit we should either do an if/else for vmware or at the least do a default fail() or use the enable on default() (incase facter ever returns anything else than vmware/physical here)
Attachment #579909 - Flags: feedback+
[cltbld@buildbot-master19 ~]$ facter virtual kvm
Tested with staging-puppet, it leaves VMs alone and turns on ntpd for ix boxes (and saw the clock get slewed to correctness on a couple of machines). Uses 'default' instead of 'physical' so we're covered if we ever move to (eg) kvm-based builders.
Attachment #590657 - Flags: review?(catlee)
Attachment #590657 - Flags: review?(catlee) → review+
Attachment #590657 - Flags: checked-in+
Deployed to the 3 masters for slaves. Clocks will slew to correct times in the few mins after ntpd starts, so if a slave picks up a job immediately there might be some funkyness around doing a clobber or not, but otherwise only make the slave's twistd.log funky.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: