Timeout when running xcodebuild tests under Xcode 6 via SSH

Question

I seem to be having issues with integrating Xcode6 with jenkins, I currently have this setup and working with Xcode 5.

With xcode 6 running remotely via SSH the simulator time-out, when I run locally it succeeds.

Command

xcodebuild -workspace PROJECTNAME.xcworkspace -scheme BGO_Tests -destination 'platform=iOS Simulator,name=iPhone 5s' -derivedDataPath ./Build clean test

2014-08-19 10:46:36.591 xcodebuild[33966:381f] iPhoneSimulator: Timed out waiting 120 seconds for >simulator to boot, current state is 1.

Testing failed: Test target BGO_Tests encountered an error (Timed out waiting 120 seconds for simulator to boot, current state is 1

Tested with recent Xcode 6 beta 6

Carsoncarstensz

I had similar problem with running tests with calabash: github.com/calabash/calabash-ios/issues/251. I suppose You're not using calabash but reason may be similar. – Bipartisan

@Bipartisan I am also using calabash but having issues with both, I wanted to solve unit tests first. – Carsoncarstensz

I'm sorry but really no idea how to help You. Will ask my mate in a moment. – Bipartisan

Still happening with GM version of Xcode 6. Also mentioned here github.com/facebook/xctool/issues/404 – Carsoncarstensz

We at Bitrise use a server based solution, you can find it on GitHub. It seems that you have to run xcode unit tests from a process which was started from the user's GUI (for example with a ~/Library/LaunchAgents agent/daemon). – Chrissychrist

also experiencing this problem. we ran unit tests in the simulator just find in Xcode5, but now they timeout in Xcode6 gold master – Spheroidicity

Answer 1

I finally managed to find a good simple solution. JNLP was causing numerous issues with our jenkins server.

Workaround for SSH timeout via https://corner.squareup.com/2015/07/ios-build-infrastructure.html

"Mavericks (10.9) and Yosemite (10.10) determine if a process can access accessibility hooks via the parentage of the accessing process. By putting launchd in the list of allowed processes, processes launched via SSH or Jenkins have access to the accessibility hooks across the system. To do this you can modify the TCC database, per this gist. A reboot is required to make the change take effect."

#!/bin/bash

# This will add lauchd to the list of allowed processes for accessibility access
sudo sqlite3 /Library/Application\ Support/com.apple.TCC/TCC.db "INSERT or REPLACE INTO access VALUES('kTCCServiceAccessibility','/sbin/launchd',1,1,1,NULL)"

# This outputs the rows in the TCC database
sudo sqlite3 /Library/Application\ Support/com.apple.TCC/TCC.db 'select * from access'

echo "Restart is required for these changes to take effect"

Update 8/02/2016 This is now fixed in Xcode 7.2.1 ("Command line tool ‘xcodebuild test’ will no longer time out waiting for Simulator.app to launch")

Carsoncarstensz

Answer 2

Note: the device names changed in Xcode 7, so you no longer specify them using iPhone 5 (9.1 Simulator) but rather iPhone 5 (9.1).

Use xcrun instruments -s to get the current list of devices and then you can pre-launch it using:

xcrun instruments -w "iPhone 5 (9.1)" || echo "(Pre)Launched the simulator."

---

Prelaunching

I got to a point where what I proposed down there wasn't working anymore. In addition to making the changes mentioned here, you need to launch the simulator xcodebuild is expecting BEFORE xcodebuild is ran:

# First get the UDID you need
xcrun instruments -s

# Then launch it
open -a "iOS Simulator" --args -CurrentDeviceUDID <sim device UDID>

# and wait some time....
sleep 5

# Then launch your unit tests
xcodebuild [...] -destination 'platform=iOS Simulator,name=<device name matching the UDID>' 

Old post

This bug is fixed in Xcode 6.3 and above. If you are experiencing similar problems in newer Xcode, it's likely another bug.

Apple follow up regarding Bug ID# 18001199:

The context provided by LaunchDaemons is not supported for running GUI applications. The SSH service, and the default setup for Jenkins, are both implemented as LaunchDaemons. In earlier versions of Xcode 5 xcodebuild could run tests on the iOS simulator in this context, but that was never a supported configuration, and as you have noted that is no longer working as of Xcode 6.

Unlike LaunchDaemons, LaunchAgents provide a context where you can run GUI applications - if the user is logged in at the time, with a window server / Aqua session. Converting your Jenkins configuration from being a LaunchDaemon to being a LaunchAgent would avoid the reported issue. You can also use launchd for running tests on the iOS simulator from a SSH session, either by crafting a LaunchAgent and manually loading / starting that, or by using "launchctl submit”.

Ok, after some more digging around the comments around here (many thanks to Opal), I found out that launching the slave via JNLP instead works.

As many people mentioned, it is not currently possible to run the unit test over SSH, so you might want to turn towards the JNLP agent for now until Apple fixes it.

---

If connecting with JNLP still does not solve it, try the solution mentioned in this comment.

i.e.: Run these on command line:

DevToolsSecurity -enable

sudo dscl . -append /Groups/_developer GroupMembership "user-that-runs-the-sim"

security authorizationdb write system.privilege.taskport is-developer

See References here and here.

I've recently found out that if you install a new version of Xcode and do not launch it. The simulator might start timing out again. To solve this, I've had to manually launch Xcode, and install the additional tools it requested.

Ines

Do you have any instruction on using Java web start (), I have a Mac Pro with 3 Virtual machines running on it. All of these are configured as Jenkins slaves. The Master jenkins node runs linux. – Carsoncarstensz

JNLP is the web start agent (afaik), checkout this link for more detail on how to set it up. – Ines

Tested this answer today and it works great thanks for the instructions, I also had to update my version of ocunit2junit to support the new output. – Carsoncarstensz

I would skip the JNLP connection suggestion and just go straight to running the suggested 3 command fix. This worked great for me, and my tests still run through SSH like they always did. – Fluoridation

Oh it did? Pretty sure I tried those directly with no avail. Thanks for sharing! Will try again. – Ines

I'm really curious what they mean here : You can also use launchd for running tests on the iOS simulator from a SSH session, either by crafting a LaunchAgent and manually loading / starting that, or by using "launchctl submit”. Starting WHAT ? – Neddie

Did anyone figure out how to use launchctl submit? I'm trying it and it just adds my command to list of launch agents, but doesn't start it. Even if I try launchctl start, nothing happens. – Dm

I've tried these commands on Yosemite with Xcode 6, and I still get the "Timed out waiting 120 seconds for simulator to boot..." message when attempting to run the tests via ssh. It seems TravisCI figured out a way, but I don't know what it is yet. github.com/travis-ci/travis-ci/issues/2829 – Opt

Are you also using the JNLP agent and auto-logging that user instead of SSH? I am also experience some intermittent issues with Xcode 6 and Yos. And I have to say it, Apple is not making our life easier. Also try to reset the simulator before you run the unit test: gist.github.com/micap/eea5f4d02a7e8e4123f0 – Ines

Answer 3

I ended up solving this on Xcode 5 by doing the steps here, essentially running:

sudo security authorizationdb write system.privilege.taskport allow

This will eliminate one class of these authentication popups. You’ll also need to run:

sudo DevToolsSecurity -enable

However, once I upgraded to Xcode 6, I now get an infinite hang when trying to run xcodebuild tests over SSH. They continue to run just fine as long as I'm logged into the console, and running them from the keyboard.

Thermoluminescence

I already had those settings turned on for Xcode 5, the issue is I cannot get my CI environment to launch the simulator without a GUI session. – Carsoncarstensz

I opened up a ticket with Apple on this. They acknowledged it was a problem, gave a workaround as starting the Jenkins slave as a JNLP - which doesn't help me at all as I'm on Thoughtworks Go. Will let you know if I get a resolution. – Thermoluminescence

@Thermoluminescence Do you have the RADAR for this? I'd like to DUP it with Apple. – Willock

Answer 4

I ran into the same issue. My working theory is that SSH on OSX is started as a LaunchDaemon, and LaunchDaemons are not allowed to present a UI; Reference.

I was able to work around the issue by using Java Web Start to launch the Jenkins slave. I then installed the Jenkins slave as a launchd service.

Unfortunately the Jenkins slave then installs itself as a -you've guessed it- LaunchDaemon, leading to the exact same problem of not being able to launch the tests; Reference.

I worked around that issue by moving the Jenkins Slave LaunchDaemon plist and jar files in /System/Library/LaunchDaemons into ~/Library/LaunchAgents, and updated the paths inside the plist file.

That finally allowed me to run XCode6 (Beta6) tests on an OSX jenkins slave.

Antonantone

Hi Mark, I use a Mac Pro with multiple VM's for builds, this solution seems very manual. I have tried running it directly via SSH from another mac and it encounters the same issue so it can't be jenkins specific. Any other ideas? – Carsoncarstensz

We at Bitrise use a server based solution, you can find it on GitHub. Indeed it seems that you have to run xcode unit tests from a process which was started from the user's GUI (for example with a ~/Library/LaunchAgents agent/daemon). – Chrissychrist

I had the same problem, and I moved the plist file to the LaunchAgents, But it's still not working. Did you do anything else to make it work? thanks. – Letti

Answer 5

I've seen this error before, one possibility is that since you probably downloaded the Xcode6 Beta from the internet (not the appstore as its not available yet), the machine you are trying to run it on will show a pop up asking you if you really want to open this app as its from the internet.

The same will happen when xcodebuild tries to launch the iPhone simulator app.

One thing you might want to try is to share screen with the machine and click "Open" in that pop up.

If that still doesn't work, I would try to:

1. Reset the Content & Settings of the simulator
2. Reboot the machine and make sure no simulator is running on start up (you can just choose not to re-open any app when restarting)

Ines

Hi Michael I have tried all of these options unfortunately I can run xcode 6 and the simulator fine via vnc and command line, just the ssh xcodebuild doesn't work correctly (simulator not launching). – Carsoncarstensz