BigSur: Opening app with open command fails with OSLaunchdErrorDomain error

Question

Created Oct ’20

Replies 3

Boosts 0

Views 5.2k

Participants 3

We have an app which is distributed outside the appstore and the app is cleanly Notarised. When I try to open the app using

Code Block bashopen /Applications/<appname.app>

I get the following error sometime

Code Block bashThe application cannot be opened for an unexpected reason, error=Error
Domain=RBSRequestErrorDomain Code=5 "Launch failed."
UserInfo={NSLocalizedFailureReason=Launch failed.,
NSUnderlyingError=0x7ffa82413830 {Error Domain=OSLaunchdErrorDomain Code=125
"Domain does not support specified action"
UserInfo={NSLocalizedFailureReason=Domain does not support specified action}}}

This issue is intermittent and happens 20% of time. Our codesigning and Notarisation everything is clean.

To give more context, the app comes with a native installer and in the Postinstall script we try to start the app by using open command, so that as soon as the installation completes the application comes up. Thats where we are running into this issue.

This does not happen till Catalina and we are seeing it only in BigSur latest beta. Any help is appreciated. Thanks.

Boost

Answer 1

DTS Engineer OP

Apple

Oct ’20

To give more context, the app comes with a native installer and in the
Postinstall script we try to start the app by using open command

This isn’t something we support. The issue here is that your postinstall script does not run in a standard GUI login context (by definition, because it’s running as root) and thus can’t reliably do GUI operations. This can cause problems in various circumstances, including:

If there are multiple GUI users logged in, either by fast user switching or via Screen Sharing, which GUI session does the app launch in?
If a site admin runs your installer remotely when no GUI user is logged in, where does the app launch?

It sounds like you’ve found another edge case (-:

Honestly, I recommend that you just not do this. If you install your app in the Applications directory, users generally won’t have a problem finding it and launching it.

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

0

Answer 2

svprakash001 OP

Oct ’20

Thanks a lot @eskimo.

The app does not have a GUI. The main binary is command line only.

Its an enterprise background app & end users don't bother to run it. It is mostly installed on the employe's mac by admins.
Technically we do have a GUI, but that GUI is a separate binary(which is not the main binary) within the app package which will be spawned as a separate process.
GUI to main app communication happens via application level API calls

Some relevant info:

The app(i.e., the main binary) registers a tray icon with bunch of controls and GUI process can be explicitly launched by the user from a tray option.
There are many separate binaries in the package - two for daemons(will be spawned whenever machine comes up by copying to /Library/LaunchDaemons) and two for agents (will be spawned whenever a user logs in by copying to /Library/LaunchAgents). Plus the GUI binaries mentioned above which will be launched based on user action.

One of this agents is designated as the main binary of the app in Info.plist.

This copying of plist also happens in postinstall script.

Now, as soon as the app is installed, launch plists are not loaded (my understanding is daemon plists are loaded when the machine is restarted next time & agent plists are loaded when users logs in next time). But we need the app to run right after installing

There are two ways to solve this:

Code Block bashlaunchctl load <plist path>  --> To load the launch plists immediately which will bring up the process  (or)
open <Binary path>       --> Explicitly launch desired process

We used first option to immediately bring up the Daemons and second option for bringing up our agents. This second option based on open command is what failing intermittently. Just to reiterate these agents don't have any GUI except tray icon.

0

Answer 3

Etresoft OP

Oct ’20

We used first option to immediately bring up the Daemons and second option for bringing up our agents. This second option based on open command is what failing intermittently.

Why aren't you doing that for both?

Also, I'm confused about this part:

daemons(will be spawned whenever machine comes up by copying to /Library/LaunchDaemons) and two for agents (will be spawned whenever a user logs in by copying to /Library/LaunchAgents).

This copying of plist also happens in postinstall script.

You definitely should copy these plist files in the post install. But you should not "also" do that. The post install is the only time you should copy those files.

0