Accessing Window Server and other GUI services when running tests via SSH vs LaunchAgent

Question

Created 1d

Replies 5

Boosts 0

Participants 2

According to Technical Note TN2083 the Window Server advertises itself in the global bootstrap namespace, which is why you can launch GUI applications from SSH sessions, even if sshd/sshd-keygen-wrapper is launched as a launch daemon (in a non-GUI per-session bootstrap namespace).

As I understand it this is also why SessionGetInfo() reports NO for sessionHasGraphicAccess, as the SSH session is not an Aqua session type, while CGSessionCopyCurrentDictionary() does return a valid dict, because in practice you have access to the window server.

However, the tech note advices against running GUI programs from SSH sessions, as other GUI services may not be exposed to the global or non-GUI per-session bootstrap namespace. It uses com.apple.dock.server as an example of such a service, showing how Activity Monitor has different behavior when launched via SSH than via the UI.

Based on the advice of the tech note, articles like https://aahlenst.dev/blog/accessing-the-macos-gui-in-automation-contexts/ recommends running CI UI tests via a Launch Agent instead of SSH.

Now, I've tried to reproduce the the Activity Monitor case on macOS 12 and macOS 15, and I can not reproduce the missing Dock features. The Testing with Xcode documentation also says that:

By default, when you use ssh to login to an macOS system that has no active user session running, a command-line session is created. To ensure that an Aqua session is created for an ssh login, you must have a user logged in on the remote macOS host system. The existence of a user running on the remote system forces Aqua session for the ssh login. Once there is a user running on the host system, running xcodebuild from an ssh login works for all types of tests.

Which begs the question: Does modern macOS versions expose GUI services to the global or non-GUI per-session bootstrap namespace, or otherwise enable UI testing from SSH sessions, so that UI tests can safely be run from SSH sessions (as long as the user is logged in to the remote system's UI). Has things changed in this regard?

Boost

Answer 1

DTS Engineer OP

Apple

1d

So what’s you actual goal here? To automate UI tests using xcodebuild? Or are you asking about “UI testing” in a more general sense?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0

Answer 2

torarnv OP

1d

The end goal is to automate UI testing in the general sense, in a way that does not result in false positives/negatives due to running in a slightly different environment than what an end user would.

Most CI/CD tools (GitHub, GitLab, CircleCI, Jenkins, etc) provide some sort of runner/agent that acts as the parent process of the test suites being run (which can be implemented via xcodebuild, CTest, GoogleTest, etc.).

Sometimes these runners/agents are launched as LaunchAgents, and sometimes they are running on a separate machine (host), and use SSH to run the command on the "worker node" (VM).

The latter (using SSH) has the advantage that it simplifies provisioning and CI integration quite a bit. It also matches the situation when a developer is investigating a CI test failure, as they will typically SSH into the CI node and run the test there. Having the two situations run the test in a similar fashion is advantageous.

So if running UI tests via SSH is close enough to what would be the environment when run via a LaunchAgent that would be great.

If that's not the case, then some details on why this is problematic (in practice) would be appreciated, to be able to analyze the impact and importance of moving existing CI solutions over to a different approach.

Thanks!

0

Answer 3

torarnv OP

1d

Of course the responsible process of the test suite will be different in the two cases, either ci-agent-runner if launched via a Launch Agent, or sshd-keygen-wrapper if launched via SSH.

Let's assume for this topic that the test suite is launched disclaimed, making it its own responsible process regardless of the parent process hierarchy.

0

Answer 4

DTS Engineer OP

Apple

16h

I see two factors in play here:

Type of product — If you were building an actual product to deploy widely, doing this stuff from an agent is the only option that I’m confortable with. However, your specific use case offers more wiggle room, because you’re only deploying to a limit number of fairly knowledgeable users.
UI testing — The question here is whether xcodebuild has enough smarts to run a UI test reliably even though it’s been started in an SSH session.

Unfortunately, I don’t have an answer for the second question. My focus in mainly on products rather than tools, and I’ve never dug into what, if any, smarts that xcodebuild applies to this problem.

Lemme go back to your original question:

Does modern macOS versions expose GUI services to the global or non-GUI per-session bootstrap namespace … ?

The answer to that is “No.” The rules haven’t changed in that regard.

Does modern macOS versions expose … otherwise enable UI testing from SSH sessions

The answer to that is “No, but also yes.”

Running GUI code in an SSH session is always a bad idea. However, modern versions of macOS [1] provide the infrastructure that makes it possible to cross sessions, that is, starting code in the GUI session from the SSH session.

The obvious follow-on question is whether xcodebuild uses that, and I don’t have an answer for you there.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] By “modern” I mean macOS 10.10 or later, which saw the introduction of launchd ‘2.0’.

0

Answer 5

torarnv OP

15h

Thanks Quinn!

The use-case here is UI testing, but not necessarily though xcodebuild, so any magic that xcodebuild does internally to handle being launched from a SSH session would not help in the general case.

The general case would be a suite of app bundles or standalone executables, launched via e.g. CTest. For example test-window-positioning.app which would be launched by executing test-window-positioning.app/Contents/MacOS/test-window-positioning and checking its exit code.

Running GUI code in an SSH session is always a bad idea.

The original Technical Note TN2083 lists some cases of why running GUI code from an SSH session is a bad idea (such as not being able to interact with the Dock), but these cases seem to work fine in macOS 12-15. Do you know of any concrete cases where this will be an issue? Knowing these will help analyze the potential risk of current solutions based on SSH sessions.

However, modern versions of macOS [1] provide the infrastructure that makes it possible to cross sessions, that is, starting code in the GUI session from the SSH session.

What infrastructure would this be? I know of open, but are there others?

0