Closed Bug 663993 Opened 10 years ago Closed 10 years ago

talos-r3-leopard-{054..059} displaying bluetooth dialog?

Categories

(Release Engineering :: General, defect, P1)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: dustin, Assigned: dustin)

References

Details

Attachments

(1 file, 1 obsolete file)

It looks like these newly imaged hosts are causing oranges due, philor argues, to a bluetooth dialog, although I haven't seen one yet.  That should have been fixed in bug 570843.

I see this in puppet:

    # disable bluetooth
    case $operatingsystemrelease {
        "9.2.0": {
            # disable the Bluetooth mouse-finding dialog
            file {
                "/Library/Preferences/com.apple.Bluetooth.plist":
                    owner => "root",
                    group => "admin",
                    mode => 600,
                    source => "${platform_fileroot}/Library/Preferences/com.apple.Bluetooth.plist";
            }

            # and disable the service, too
            service {
                "com.apple.BluedServer":
                    ensure => "stopped",
                    enable => false;
            }
        }

        "10.2.0", "10.6.0": {
            # the service has a different name in darwin10; the dialog does not appear, though,
            # and the plist is different from 9.2.0, so no need for it here
            service {
                "com.apple.blued":
                    ensure => "stopped",
                    enable => false;
            }
        }
    }

however, our leopard boxes are running 9.8.0 now.  I'm not sure when that changed?
talos-r3-leopard-054
talos-r3-leopard-055
talos-r3-leopard-056
talos-r3-leopard-057
talos-r3-leopard-058
talos-r3-leopard-059

all disabled for the moment in slavealloc
Priority: -- → P5
10.5.8 was January, mostly in bug 537748.
Add 9.8.0 to the list of platforms this is disabled on.  I'm not sure why this is working on the existing leopard slaves.  The ref machine has the proper plist on it.  Anyway, this should fix it.
Assignee: nobody → dustin
Attachment #539030 - Flags: review?
Attachment #539030 - Flags: review? → review?(bhearsum)
Priority: P5 → P1
Attachment #539030 - Flags: review?(bhearsum) → review?(catlee)
Attachment #539030 - Flags: review?(catlee) → review+
deployed, slaves re-enabled, and rebooted.  Let's see what happens.
Duplicate of this bug: 664025
From talos-r3-leopard-003:/var/puppet/log/puppet.out:

notice: Starting catalog run
notice: //Node[talos-r3-leopard-003]/talosslave/talos_osx/Exec[remove-index]/returns: executed successfully
notice: //Node[talos-r3-leopard-003]/talosslave/talos_osx/Exec[disable-indexing]/returns: executed successfully
notice: //Node[talos-r3-leopard-003]/talosslave/talos_osx/buildslave::cleanup/Exec[find /tmp/* -mmin +15 -print | xargs -n1 rm -rf]/returns: executed successfully
err: //Node[talos-r3-leopard-003]/talosslave/talos_osx/Service[com.apple.BluedServer]: Failed to retrieve current state of resource: Unable to find launchd plist for job: com.apple.BluedServer
notice: Finished catalog run in 3.67 seconds

The failure blocks buildbot from starting.
Turns out talos-r3-leopard-056 is actually a Snow Leopard install

talos-r3-leopard-056:~ cltbld$ uname -a
Darwin talos-r3-leopard-056.build.scl1.mozilla.com 10.6.0 Darwin Kernel Version 10.6.0: Wed Nov 10 18:13:17 PST 2010; root:xnu-1504.9.26~3/RELEASE_I386 i386

All the new slaves are disabled in slavealloc again.

And I think the bluetooth server changed name from com.apple.BluedServer to com.apple.blued
Comment on attachment 539030 [details] [diff] [review]
m663993-puppet-manifests-p1-r1.patch

I've backed this out
 http://hg.mozilla.org/build/puppet-manifests/rev/6c88d60bf093

Quite possibly we want to stop com.apple.blued on 10.5.8/Darwin 9.8.0 too, as random googling and this from talos-r3-leopard-003 indicate:
 $ locate com.apple.blued
 /System/Library/LaunchDaemons/com.apple.blued.plist
 /private/var/run/com.apple.blued.launchd

However I managed to break talos-r3-leopard-003 trying to test that with 
  sudo launchctl unload -D system com.apple.blued
as it shut down a whole bunch of services and left me without sudo. I'm hoping a reboot will be enough to recover that, but of course it'll need manual intervention to achieve that.
Attachment #539030 - Flags: checked-in-
So back in bug 570843 some n00b assumed that we were running the same flavor of darwin9 on all of our slaves, and copy/pasted this config from os/osx.pp to os/talos_osx.pp.  This worked for the snow talos machines (10.6.0), but had absolutely no effect for leopard (9.8.0 -- the puppet manifests specify 9.2.0).

If I'd done my homework back then, I would have created exactly the breakage that nthomas observed here, way back when.  So at least that mystery is solved.

I ran
  launchctl unload -w /System/Library/LaunchDaemons/com.apple.blued.plist
on talos-r3-leopard-059 without any ill effects, and verified after reboot that it com.apple.blued isn't running.
OK, let's try this one.  Turns out it's named blued on all of our talos boxes.

I tested this on one of the new leopard boxes from the staging master, and verified that it stopped the blued service and that the service did not start on reboot.  So I think we're in good shape.
Attachment #539030 - Attachment is obsolete: true
Attachment #539375 - Flags: review?(nrthomas)
Attachment #539375 - Flags: review?(nrthomas) → review+
Landed, hosts enabled, and rebooted.  I checked that blued isn't running.
Status: NEW → RESOLVED
Closed: 10 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.