On our mac ci server xcodebuild has started to run extremely slow.
When I google 'xcodebuild slow' I find a lot of questions/answers about xcodebuild slowing down the terminal (link1, link2) which is not at all my problem:
When I ssh onto the Server, it perfectly smoothly has zsh run everything in a responsive way.
I noticed the issue when our iOS ci builds started timing out:
However we have to run our builds through XCode via fastlane - But no matter what xcodebuild command I run (even xcodebuild -version) is slow to the point of broken - it will output
Xcode 13.2.1
Build version 13C100
immidiately, but then the process does not exit and block the terminal io for minutes or even hours (its not consistent)
This used to just work fine for the last year and most part of January.
Why could be the issue here?
Related
I'm just getting back into trying some front end projects for the first time in a few years. Many npm-based javascript projects I try out end up taking a long time to start up in development mode even for Hello World-ish examples. In particular I'm trying out Nuxt.js.
Dev server startup takes about 100 seconds, and nothing seems to get cached so restarts (not hot reloads) take the same amount of time. My research into the project and known npm issues did not turn up any definitive root cause or ways to improve this yet.
I'm using emacs 26.1 in terminal mode on a 2018 13" MacBook Pro with a core i5, 8 GB of ram, and an SSD.
When I run npm run dev to startup the nuxt dev server I get repeated error in process filter: Args out of range: "\342", -1 errors related to some unusual characters they are using to try to make the output pretty. If I try the same thing in a vanilla Mac OS terminal the server startup goes 10x faster. Why do those errors occur, and why is it so much slower in an emacs terminal?
It turns out the repeated error in process filter issue may be caused by a bug in term mode that was recently fixed but might still be an issue in my version of emacs.
As a workaround, the following can get the nuxt dev server running in ~10s instead of ~100s in an emacs terminal on my mac by filtering out the repeated lines about the modules being built:
$ npm run dev | grep -v modules
Note that I tried using npm's options to adjust the log level but none seem to filter this output. If anyone knows a more "official" way of filtering this, or even better, if you know how to make it such that it doesn't try to rebuild the modules on every dev server start up, I'd be interested to know.
Edit: it might make sense to adjust the dev script command in the package.json file to include the grep filter, that way you can still just type npm run dev and get the workaround.
A react native expo app run within WSL, is the cause of a very annoying bug.
A few minutes after starting the Expo project, the internet on the windows laptop stops working.
I found this command fixes it:
Restart-Service LxssManager - when run from Powershell
However, this happens many times a day and means I have to restart the Expo project every time.
Related to: https://askubuntu.com/questions/1203412/wsl-causing-my-internet-to-not-work
Equally crazily, the fingerprint sensor on my laptop stops working and works again after that command is run.
I suspect the issue is somehow related to a very short (2-5 minute) timeout related to the react native app.
If anyone is able to point in any direction, I would love any help.
Maybe it's Expo or maybe I have some kind of local app code error. But I wouldn't know where to even start or test a bug like that.
Here is a basic run-through of what happens.
Start Expo app in WSL
Work, for an indefinite time
If PC activity pauses for longer than 3 min, the error happens. No internet, no fingerprint sensor.
Run the PowerShell command, restart the app. All is good again.
This is a known bug in WSL. Microsoft has solved this bug in build 18890. https://github.com/MicrosoftDocs/WSL/blob/live/WSL/release-notes.md#build-18890
It happens when a process in WSL creates and closes a large number of non-blocking TCP sockets, and after that some ephemeral TCP ports are leaked, eventually exhausting all ephemeral ports in both the host and the WSL.
You can try upgrading your system to version 2004 or 20H2 and see if this problem persists.
I was wondering why my NUnit tests were suddenly terminating successfully after 30 seconds whereas they usually take at least 20 minutes. Then I looked into the build log and found that after upgrading the mono version on our build agent to v 5.4.1, the test runner crashed with exit code 134.
After doing some research, I found out the following:
- The test runner works when using mono 4.8.1 (which we have installed, too), but the test code won't compile with it
- Ì also tried launching th erunner manually like so: /Library/Frameworks/Mono.framework/Versions/5.4.1/bin/mono -v /Applications/TeamCity/buildAgent/plugins/dotnetPlugin/bin/JetBrains.BuildServer.NUnitLauncher.exe which gave me the following error: [1] 3461 abort /Library/Frameworks/Mono.framework/Versions/5.4.1/bin/mono -v with the 3461changing every time I retry.
- According to this thread, exit code 134 means that the program crashed.
Due to the error output, I am not sure, whether it's the TeamCity test runner that crashes, mono that crashes or TeamCity that makes mono crash.
Any help appreciated :)
I finally figured it out myself. Apparently, Mono 5.4.1 lacks important NUnit2 components that were shipped with Mono 5.2 and older. To make tests work again, I had to add the NUnit.Console NuGet-package (not NUnit.ConsoleRunner as it lacks required extensions) and update the TeamCity build step to use the nunit3-console as described here.
For others that may come across this, I fixed this by changing the NUnit build steps from NUNit 2.6.3 to the NUnit 3.10. I didn't change any of my code / packages, just the TC configuration.
While running some UI tests with selenium, I am running BrowserStackLocal.exe and I use this command:
BrowserStackLocal.exe --key browser stack license
And everything seems to run pretty good but after around half an hour, the process suddenly stops making my selenium tests fail because they can't reach the target URL.
I am running a windows 10 machine.
Has anyone experienced this before?
Thanks in advance.
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
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.
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.
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.
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")
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:
Reset the Content & Settings of the simulator
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)