Startup Items Cache Issue: New Items from the Same Team Fail

Our team has two products. The first product adds two /Library/LaunchDaemon startup items and one /Library/LaunchAgents startup item, which run normally after installation.

A few months later, our team developed another product, which adds two /Library/LaunchDaemon startup items and one /Library/LaunchAgents startup item. However, we found that on some customers' systems, these startup items for the second product do not load correctly, and the processes do not start. Restarting the system does not resolve the issue. This occurs across systems running versions 14.5 to 14.6.1.

The app's signatures, notarization, and Gatekeeper validations all pass. Eventually, we discovered that by disabling and then re-enabling our team's startup items in the System Settings - Login Items, all the startup items from our team load correctly. Could this be a caching bug related to new startup items from the same team?

In some client systems, when loading new startup items with the load -w command, issues arise if the new items belong to a team that already has existing startup items. In certain client systems, the newly added startup items fail to load with load -w, and restarting the system does not resolve the issue. Why does this occur?

It’s not entirely clear what’s going on here, but as a first step I recommend that you ensure that you’re code is signed correctly. Specifically, make sure they all have a unique code signing identifier. For bundle code this usually isn’t a problem, because it defaults to the bundle ID, but for non-bundled code it’s best to set it explicitly as part of the signing process.

Also, are these daemons and agents associated with a user-visible app on the system? If they are, make sure to set the AssociatedBundleIdentifiers property.

Share and Enjoy

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

Startup Items Cache Issue: New Items from the Same Team Fail
 
 
Q