Many apps now use helper apps and services to handle some of their work. One long-established reason for doing this is when an app needs to do something at a higher level of privilege, typically as root. Rather than the whole app running as root, just the code that needs elevated privilege is moved into a privileged helper. Other helpers might be used to manage a service from the menu bar, or to run a periodic background service.
Diagnosing problems with helper apps and services is extremely difficult, and made harder by the fact that most are now XPC services and only revealed by their entry in Activity Monitor’s lists. When they’re in trouble, they can cause almost anything, including:
- unexpected or abnormal behaviour,
- their entry in Activity monitor can take high % CPU and/or memory,
- spinning beachballs and sluggish performance,
- general instability.
Safe mode
The most important test to establish whether any such behaviour is likely to be the result of a third-party helper app or service is to start up in Safe mode and demonstrate that the problem disappears then. This is because Safe mode blocks these helper apps and services from being launched. If it doesn’t help, then it doesn’t disprove a helper app or service from being involved, but makes it less likely. Unfortunately, Safe mode doesn’t help you establish what’s the cause, nor what you should do about it.
Which Library?
In the past, most helper apps and services have been run by launchd
on the basis of property lists in LaunchDaemons and LaunchAgents folders in the main Library folder, or in ~/Library/LaunchAgents. One good way to distinguish these is to create a new user account and see if the problem affects that too: if it doesn’t, then it’s more likely that the helper app or service is being launched from the Library folder in your Home folder rather than the main Library, in other words that the problem lies somewhere in your Home folder.
Up to and including Monterey, that’s about the most systematic you can be. From there on it’s down to your suspicions, guessing which LaunchAgents and LaunchDaemons are associated with which apps, and striking lucky if it’s a login item, which is more likely to be stored in the app or its supporting folders.
Ventura
Thankfully this has changed in Ventura, in its System Settings > General > Login Items. This is just as well, as from Ventura onwards property lists that previously had to be installed in Library LaunchDaemons and LaunchAgents folders can now be kept inside their app, making them even harder to locate.
There are two distinct sections in the Login Items settings: at the top is a list of all Login Items currently recognised, and below is the list of Background Items.
Login Items
To remove a Login Item, select it in the list and click the – button to delete it. It really is that simple, although removing a Login Item installed by an app is likely to affect what it can do, and how it works. In this case, the Login Item shown starts a helper app for Carbon Copy Cloner; without that, the app loses some of its functionality.
To log in without Login Items being started automatically, press and hold the Shift key when you click on the Log In button, and keep it held until the Dock appears. Existing items won’t be opened until you log in again.
Background Items
If your Mac has been in use some years, or has been migrated from an older system, you’re likely to see many Background Items listed here. However, your control over them is limited: all you can do is turn them off and on. If you try disabling some of them, you may see that they’re automatically re-enabled. Many appear unidentifiable. A few have Info buttons, revealing where they are on your Mac, but many don’t. One useful piece of information given for some is whether that item affects all users, in other words is in a folder outside your Home folder, which includes the main Library and Applications folders.
The nuclear solution is to blow the whole lot away, and start from scratch, but if you don’t then delete those old apps and their components, including property lists and support files tucked away in Application Support, LaunchAgents and LaunchDaemons folders, then many will return to haunt you. To remove all third-party Login Items and reset to installation defaults, you can use the undocumented command
sudo sfltool resetbtm
This uses a command tool originally intended to manage the Shared File List, which has gained additional features covering Service Management, although its man page hasn’t caught up yet and the most help you’ll get is from its usage info.
A better and more systematic approach is to obtain a detailed listing of all those Background Items, and uninstall or delete those you no longer need, or are just old and unnecessary. For this, you need a BTM dump, using another undocumented option to the sfltool
command:
sudo sfltool dumpbtm > ~/Documents/btmdump.text
to write it to the text file btmdump.text in your Documents folder. This file is also invaluable if you’re going to nuke Login Items in a reset, as it provides a record of what you might need to restore afterwards.
BTM dump
This lists full Service Management information for every item currently being managed, by user ID. Normally, the two important user IDs would be 0 for root and 501 for the primary admin user, but here the first list, with a UID of -2, appears to be a composite covering most Background Items. You should also check those for the current user, such as 501. A typical entry might be:
#28:
UUID: 58AA238A-CE72-4A09-BB6B-627A0D51CBC0
Name: com.microsoft.autoupdate.helper
Developer Name: Microsoft AutoUpdate
Team Identifier: UBF8T346G9
Type: curated legacy daemon (0x90010)
Disposition: [enabled, allowed, visible, notified] (11)
Identifier: com.microsoft.autoupdate.helper
URL: file:/// Library/LaunchDaemons/com.microsoft.autoupdate.helper.plist
Executable Path: /Library/PrivilegedHelperTools/com.microsoft.autoupdate.helper
Generation: 3
Assoc. Bundle IDs: [com.microsoft.autoupdate2 ]
Parent Identifier: Microsoft AutoUpdate
When removing Background Items, this gives the location of the Property List used by launchd
to load them, as the URL, and the location of the executable that is loaded. The Developer Name given is taken from the code signing certificate. The Disposition field is probably most relevant to identifying those causing problems, as it should reflect the status of that entry in the Login Items list, and whether the user has been notified. There’s currently no way to change or correct those, at least using the tools available.
Finally, any changes you make to these items won’t be reflected in the Launch Items lists until Service Management maintenance has been run overnight.
Summary
- Login and background items can cause a wide range of generic problems.
- Clues may come from processes in Activity Monitor.
- Start up in Safe mode to discover whether this is likely to be the result of third-party software rather than the system itself.
- Create a new user account and log into that to discover whether the culprit is likely to be in ~/Library rather than /Library.
- In Monterey and earlier, discovering what’s responsible is educated guesswork.
- In Ventura, use System Settings > General > Login Items
- Temporarily disable all Login Items by pressing and holding the Shift key when you click on the Log In button, and keep it held until the Dock appears (Ventura).
- If the responsible Background Item isn’t obvious, obtain a BTM dump and browse that (Ventura).
Further reading
Apple’s traditional approach (2016)
New Service Management scheme