Legacy LaunchAgents installed via PKG

I customize an open source app (yo), sign it, and deploy it to a bunch of Macs. We've been doing this for almost 4 years and it relies on 2 LaunchAgents that run a python script.

With the move to Ventura, I discovered the background items and that this particular item shows up as 2 "yo_scheduler" items I have now:

  1. signed the python script
  2. add AssociatedBundleIdentifiers to the LaunchAgents
  3. Call LSRegisterUrl as part of the postinstall script

I've packaged all this up, and install it on clients. Based on the documentation, I would anticipate that these 2 items would now show up as "Yo.app" but they don't. They show up as our developer program name.

Based on some discussion with other Mac admins it sounds like we have to register AND open the app before the LaunchAgents are actually installed.

If I install, then run sfltool resetbtm, then restart the Mac this all shows up properly...

What's the proper way to use legacy LaunchAgents installed by a PKG?

Post not yet marked as solved Up vote post of pboushy Down vote post of pboushy
1.4k views
Posted by
pboushy
Reply
  • What's the proper way to use legacy LaunchAgents installed by a PKG?

    I was wondering the same thing as well. We see this where both our daemon and agent in the "Allow in Background" list in the Ventura System Settings show up as our developer name rather than the application name from 'AssociatedBundleIdentifiers' in the plist files. And, if we register AND open this app before the LaunchAgent and LaunchDaemon are loaded then it works but this is tricky to implement in an installer package.

    —
    jnjc

  • We're running into similar problems with the app name not being shown in the system settings. Please let us know if you find a solution. How do you call LSRegisterUrl in the postinstall script? Do you have a dedicated binary for that?

    —
    wriker

  • We have a similar problem. After adding the AssociatedBundleIdentifiers to the LaunchDaemons' plist files they are at least labeled with the developer name instead as before with something completely unrelated. Then we tried to start the app in the postinstall before loading the LaunchDaemons. Now one item has the name of the app, the other one has still the developer name. It seems the notification banners appear when starting the app, not when loading the LaunchDaemons. Is that possible?

    —
    lenamaria
Add a Comment

Replies

Were you able to solve your problem? Facing the same issue.

Posted by
wriker
Up vote reply of wriker Down vote reply of wriker
Add a Comment

I would also like to know if there is a solution. We have the same issue.

Our product is rather complex with an application, a daemon, an agent plus some other components (like an authorization plugin) so it is just simpler to install via a package (built with productbuild --distribution). We have added the AssociatedBundleIdentifiers key to the launchd plist for both the daemon and agent but they still show under our developer name and not the application in System Settings after installing. It is only after running sfltool resetbtm and restarting that the daemon and agent show with the application name.

I have tried using /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister to register the application in its postinstall script (which executes before the daemon or agent gets installed) but that didn't help.

Posted by
mdobro
Up vote reply of mdobro Down vote reply of mdobro
Add a Comment

Someone opened a DTS tech support incident about this. I think I found a reasonable workaround but I need to do further research before talking about it publicly. I’ve made a note to update this thread once that’s done.

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

Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Add a Comment

@eskimo : Did you get anywhere with your research? I have just run into this issue too.

Posted by
hhhh
Up vote reply of hhhh Down vote reply of hhhh
Add a Comment

Did you get anywhere with your research?

Not really. My ‘cunning plan’ was to explicitly register the ‘parent’ app with Launch Services in the installer package’s post-install script before copying the agent’s launchd property list to /Library/LaunchDaemons. This helps in some situations but the developer I was working with still managed to hit cases where it fails.

At this point I’m out of ideas and my advice is:

  1. Make sure the problem reproduces on the latest system running on a ‘fresh’ machine. That is, one that’s never seen your product before. I generally do this sort of testing in a VM, restoring to a fresh snapshot between each test.

  2. If so, file a bug, including a copy of your product and a sysdiagnose taken shortly after reproducing the problem.

If you do file a bug, please post your bug number here, just for the record.

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

Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Add a Comment