Closed Bug 786679 Opened 12 years ago Closed 11 years ago

10.8 slaves have the Bluetooth Keyboard Setup dialog up and running

Categories

(Infrastructure & Operations Graveyard :: CIDuty, task)

Product:
Infrastructure & Operations Graveyard
Component:
CIDuty
Platform:
x86_64
macOS
Type:
task
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: philor, Assigned: kmoir)

References

Details

Attachments

(2 files, 2 obsolete files)

Screenshot
61.56 KB, image/png
Details
patch
4.92 KB, patch
dustin
: review+
kmoir
: checked-in+
Details | Diff | Splinter Review 
We may wind up having to live with it, since we never managed to defeat it on 10.7, but filing because it's going to be seen in logged screenshots, like https://tbpl.mozilla.org/php/getParsedLog.php?id=14799452&tree=Try, whether or not it actually causes test failures the way it did for 10.6, where we did manage to defeat it with bug 570843.
Blocks: 764948
Assignee: nobody → kmoir
https://tbpl.mozilla.org/php/getParsedLog.php?id=20079817&tree=Mozilla-Inbound

Also, we should disable restarting crashed apps like in bug 843545
Attached patch patch (obsolete) — — Splinter Review 
tested in staging
Note I couldn't call osxutils::defaults because that just configures an existing key, cannot create a new one, not sure if it's worth rewriting that.
Attachment #718461 - Flags: review?(rail)
Comment on attachment 718461 [details] [diff] [review]
patch

I think that's definitely worth fixing, rather than working around its lack.
Attachment #718461 - Flags: review-
Comment on attachment 718461 [details] [diff] [review]
patch

Can't go against the puppetagain founding father! :)
Attachment #718461 - Flags: review?(rail)
Sorry to jump on your r?, and I hope you're kidding and feel like you *could* contradict me if you felt I was incorrect.
(In reply to Dustin J. Mitchell [:dustin] from comment #7)
> Sorry to jump on your r?,

No worries. It's totally OK.

> and I hope you're kidding and feel like you
> *could* contradict me if you felt I was incorrect.

Yeah, that was a joke :)
Attached patch patch (obsolete) — — Splinter Review 
I can use osxutils::defaults. I don't have to specify bool as a type, I can just give 0 as a value. Tested on a staging slave.
Attachment #718461 - Attachment is obsolete: true
Attachment #719716 - Flags: review?(dustin)
Attachment #719716 - Flags: review?(dustin) → review+
Attachment #719716 - Flags: checked-in+
verified that slaves are updated with this preference
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
We're started seeing OS X 10.8 test timeouts appear on multiple trees - any chance this could have backfired?
(First instance ~ 2 hrs ago)
Attached image Screenshot — 
Screenshot from a run that has timed out.

Take it that's the screensaver?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Whiteboard: [buildduty]
Severity: normal → blocker
All trees are closed
talos-mtnlion-r5-010 has an older plist. Would it work if we reverted to that?

talos-mtnlion-r5-010:~ cltbld$ ls -l /Library/Preferences/com.apple.Bluetooth.plist
-rw-r--r--  1 root  wheel  1879 28 Aug  2012 /Library/Preferences/com.apple.Bluetooth.plist
dustin@euclid ~/tmp $ diff -au 010.plist 011.plist 
--- 010.plist   2013-03-01 13:16:28.000000000 -0500
+++ 011.plist   2013-03-01 13:16:10.000000000 -0500
@@ -2,6 +2,10 @@
 <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
 <plist version="1.0">
 <dict>
+       <key>BluetoothAutoSeekKeyboard</key>
+       <string>0</string>
+       <key>BluetoothAutoSeekPointingDevice</key>
+       <string>0</string>
        <key>BluetoothVersionNumber</key>
        <integer>3</integer>
        <key>ControllerPowerState</key>
@@ -13,7 +17,7 @@
                        <key>ClassOfDevice</key>
                        <integer>3670276</integer>
                        <key>ClockOffset</key>
-                       <integer>9158</integer>
+                       <integer>19743</integer>
                        <key>EIRData</key>
                        <data>
                        DQltYWMtc2lnbmluZzENAxIRDBEBEQAQHxEDEg7/TAABTWFjbWlu
@@ -25,11 +29,11 @@
                        AAAAAAAA
                        </data>
                        <key>InquiryRSSI</key>
-                       <integer>189</integer>
+                       <integer>188</integer>
                        <key>LastInquiryUpdate</key>
-                       <date>2012-08-28T14:06:00Z</date>
+                       <date>2012-08-09T15:44:02Z</date>
                        <key>LastNameUpdate</key>
-                       <date>2012-08-28T14:04:02Z</date>
+                       <date>2012-08-09T15:32:25Z</date>
                        <key>ModelIdentifier</key>
                        <string>Macmini4,1</string>
                        <key>Name</key>
@@ -46,7 +50,7 @@
                        <key>ClassOfDevice</key>
                        <integer>3670276</integer>
                        <key>ClockOffset</key>
-                       <integer>10456</integer>
+                       <integer>4375</integer>
                        <key>EIRData</key>
                        <data>
                        DQltYWMtc2lnbmluZzINAxIRDBEBEQAQHxEDEg7/TAABTWFjbWlu
@@ -58,11 +62,11 @@
                        AAAAAAAA
                        </data>
                        <key>InquiryRSSI</key>
-                       <integer>195</integer>
+                       <integer>199</integer>
                        <key>LastInquiryUpdate</key>
-                       <date>2012-08-28T14:06:06Z</date>
+                       <date>2012-08-09T15:44:12Z</date>
                        <key>LastNameUpdate</key>
-                       <date>2012-08-28T14:04:03Z</date>
+                       <date>2012-08-09T15:32:25Z</date>
                        <key>ModelIdentifier</key>
                        <string>Macmini4,1</string>
                        <key>Name</key>
@@ -77,7 +81,7 @@
        </dict>
        <key>PANInterfaces</key>
        <array>
-               <string>80-49-71-14-3c-42</string>
+               <string>80-49-71-14-3e-62</string>
        </array>
        <key>PersistentPorts</key>
        <dict>

So yes, I'd say that will fix it.
Well, it will revert it.  The screensaver's not actually disabled anyway (per bug 764948#c64).  Something about not disabling bluetooth prevents the screensaver from activating.  So "fixed" isn't the right word.
I deployed the old plist to all production mtnlion slaves.
RyanVM is looking at re-triggering them.
I will re-trigger them.
We should know around 11:35am PDT if we're back to normal.
Attachment #719716 - Flags: checked-in+ → checked-in-
Severity: blocker → major
Whiteboard: [buildduty]
Blocks: 788999
Today I:
1) imaged a slave
2) ran the puppet against my environment to disable bluetooth setup assistant for keyboard and mouse
3) ran a find with a recent mtime to find files that had recently changed on the entire filesytem and grepped through the plists to find weird changes - found nothing
4) Noticed there isn't a com.apple.screensaver plist I can modify on these boxes to disable the screensaver 
5) Noticed that defaults read on my freshly imaged slave is empty which is weird. The slaves in production do have defaults.
6) Compared defaults on my personal 10.8 machine without and with the screen saver enabled
 
 "NSWindow Frame Main Window Frame SystemPreferencesApp 8.0" = "750 324 668 528 0 0 1680 1028 ";
---
>         "NSWindow Frame Main Window Frame SystemPreferencesApp 8.0" = "750 306 668 546 0 0 1680 1028 ";

This doesn't exist in the default settings for the mtnlion slaves.

At this point, I don't know how to proceed to fix this issue.
My suggestion might be to just rename /System/Library/CoreServices/Bluetooth\ Setup\ Assistant.app/ to something else so it doesn't start. But that is very hacky.
What happens when you disable bluetooth as well as the screensaver? (rather than just bluetooth) Do we have the problem after that?

I believe if you change through the GUI the screensaver settings it till generate a plist which we can most likely use (IIUC).

Forgive me if you answered that in the previous comment. I wasn't sure if you just compared your local machine and mtnlion machines for the screensaver settings.
I looked at it this morning and figured out how disabling the bluetooth setup assistant enabled the screen saver

pmset shows the power management settings

talos-mtnlion-r5-026:Preferences root#  pmset -g assertions
3/8/13 7:23:13 AM PST    
Assertion status system-wide:
   PreventUserIdleDisplaySleep    1
   CPUBoundAssertion              0
   PreventSystemSleep             0
   PreventUserIdleSystemSleep     0
   ExternalMedia                  0
   UserIsActive                   0
   ApplePushServiceTask           0
   BackgroundTask                 0

Listed by owning process:
  pid 305(Bluetooth Setup): [0x0000000500000140] 01:40:56 PreventUserIdleDisplaySleep named: "Bluetooth Setup Assistant" 

Kernel Assertions: None
talos-mtnlion-r5-026:Preferences root# ps -ef | grep -i bluetooth
   28   305   142   0  5:42am ??         1:04.80 /System/Library/CoreServices/Bluetooth Setup Assistant.app/Contents/MacOS/Bluetooth Setup Assistant -autoConfigure
    0   909   787   0  7:23am ttys000    0:00.00 grep -i bluetooth

The bluetooth setup assistant is currently setting PreventUserIdleDisplaySleep to 1 so the screen saver isn't activated.  

Armen: on my freshly imaged and puppetized slave, I can't change any settings in system preferences.  If I change something, close system preferences and then start it again, the old preferences return.  This is without puppet running. Perhaps this is because the cltbld user doesn't have administrator privileges on the machine.
Saw this in the screenshot for the following

using slave: talos-mtnlion-r5-030

https://tbpl.mozilla.org/php/getParsedLog.php?id=20471687&tree=Mozilla-Beta
I tried many combinations of setting the screen saver so it wouldn't be enabled 

defaults write /Library/Preferences/com.apple.screensaver.plist idleTime 0
#get UUID
ioreg -rd1 -c IOPlatformExpertDevice | grep -i "UUID" | cut -c27-62
defaults write /Users/cltbld/Library/Preferences/ByHost/com.apple.screensaver.2775AD39-C220-50B7-89A2-2696BF32EBA5 idleTime 0
chmod and chown the above plist so cltbld has access
defaults -currentHost write com.apple.screensaver idleTime 0
defaults write com.apple.screensaver -dict com.apple.screensaver idleTime 0

None of them worked. 

Also, if I add a new user and change their screen saver preferences via the ui, there are new plists created, but again, I can't do this as the cltbld user.  Also, I checked Apple's support site, and they describe how to change the screen saver preferences via defaults for earlier versions of osx, but not 10.8.  Not sure what to do from here.
Maybe we should return Mountain Lion to apple on an RMA.  It's broken in so many ways.. (kidding, for the record)
dustin, do you know if we have a support line we can call?
or any specialist in the matter?

Would re-adding the Admin user help to fix the issue?

Do we know of a good forum where we can find people who can answer this?

I think we can figure it out and write a very useful blog post for the rest of humanity :D
I've found the problem.  

I thought that this plist was correct 
defaults write /Users/cltbld/Library/Preferences/ByHost/com.apple.screensaver.2775AD39-C220-50B7-89A2-2696BF32EBA5 

because this is the same file that changes on my 10.8 laptop when I change the screen saver.  But I didn't understand why I couldn't change this in the ui.  It turns there was a permission problem on ~cltbld/Library/Preferences from our appstate module.

http://mxr.mozilla.org/build/source/puppet/modules/clean/manifests/appstate.pp

The ~cltbld/Library/Preferences directory was owned by root. It needs to be changed to be owned by cltbld user.  When I add the defaults write for the screensaver plist I'll have to change ownership for it as well.

After added the plist and chowned the directory, I was able to see that the screensaver was disabled in the ui.  

So it wasn't Apple, but our own puppet configs.

I'll write a patch.
Attached patch patch — — Splinter Review 
This patch disables the bluetooth setup assistant and the screensaver. It also fixes some permission issues.  I also removed "--currentHost" from osxutils::defaults because this isn't needed (it just restricts the preference changes to the current host) and having it by default caused issues with the screensaver plist. The modules that use the osxutils::defaults are 
modules/clean/manifests/appstate.pp 
disableservices/manifests/common.pp
modules/users/manifests/builder/autologin.pp
modules/vnc/manifests/init.pp

I verified these the commands for these modules work with -currentHost removed  as expected.
Attachment #719716 - Attachment is obsolete: true
Attachment #723304 - Flags: review?(dustin)
Comment on attachment 723304 [details] [diff] [review]
patch

Nicely done!  Just some indentation fixes in common.pp (indent the resource titles four more spaces).
Attachment #723304 - Flags: review?(dustin) → review+
Status: REOPENED → RESOLVED
Closed: 11 years ago → 11 years ago
Resolution: --- → FIXED
No longer blocks: 788999
Product: mozilla.org → Release Engineering
Component: Platform Support → Buildduty
Product: Release Engineering → Infrastructure & Operations
Product: Infrastructure & Operations → Infrastructure & Operations Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: