As software advances so do the installers, which have become vehicles for all kinds of needless bloat ware. I do not believe this to be an inevitably, its possible for software to progress without demanding more space and resources—directly, or indirectly, through the numerous "Helper" apps they propagate.

Even the dæmons (background processes) built into the operating system are way too numerous, attempting connections countless times each hour for menial tasks like checking data and time (which only changes twice a year!) by querying what appears like a small list of domains, but which resolve to hundreds of ip addresses. Many of them suspicious.

This is but one example. Anyone who has installed Creative Cloud knows that even if you never launch an app, there are about a dozen background apps each with their own daemons doing god knows what.

I have a subscription to Creative Cloud, that isn't the issue.

I want to know the safest way to prevent some of them (the resource-hoggers) from opening, to help my system run smoother.

In the past I've simply replaced one of the unimportant binaries with one of my own, renamed as the original, so that when Adobe forces it to load, it does something innocuous like clear my RAM. This usually works until it's time to update.

Is there a way to know which daemons can be changed without a negative outcome? Or to install software with an app like Pacifist to customise which daemons get left out?

I just want my Mac to run smoother, and the daemons in question cannot be quit once open, and deletion usually corrupts the app— replacing is the only way I've found to circumvent the hogging of resources.

1 Answer 1


Moscarda, friend:

These are good points, each, and I agree with your conclusion that the list of system daemons or services which are running after the operating system installation is rather excessive.

Between performance and ease-of-operation I readily prefer performance. Thus, I tend to reduce to bare minimum the list of services which are allowed to run. I also expect that if something fails to work auto-magically, that I probably need to launch a particular system service which got disabled as a consequence of my preference for performance over ease-of-operation.

Apple has made disabling services rather elegant via launchd in the more recent versions of its operating system. To a system administrator's dismay, however, Apple continues to allow the historic, deprecated means of launching services and therefore some third-party software still uses the likes of SystemStarter. SystemStarter is a direct descendant of historic BSD rc (resource control) and System V init processes. While being more modern than the historic UNIX parents it descends from, SystemStarter is still a far cry from the more evolved functionality and elegance of launchd.

My procedure:

  1. Preserve a copy of the original state of configuration by making a backup of relevant files.

     mkdir /private/var/archive ; tar -czvf /private/var/archive/SERVICES_$(date '+%Y-%m-%d-%H:%M:%S').tar.gz /System/Library/StartupItems /System/Library/LaunchDaemons /System/Library/LaunchAgents /Library/StartupItems /Library/LaunchDaemons /Library/LaunchAgents ~/Library/StartupItems ~/Library/LaunchDaemons ~/Library/LaunchAgents 
  2. Inspect what still relies on the deprecated StartupItems and disable anything relevant by removing its items from the ( ~/ | /Library/ | /System/Library/ ) StartupItems folder.

Please remember this: These paths ~/, /Library/, /System/Library/ are listed in order of their importance and therefore sensitivity to potential errors that might affect the ability of your machine to boot properly or behave normally. Use caution, and when in doubt, recover from the archive the original file, replacing any edited files in error.

  1. Identify what is running via launchd:

     launchctl list | grep -v '^-' | sort -nr -k 1
  2. Test system stability and needed functionality by stopping the services identified in step 3:

     launchctl stop [service name] ; launchctl remove [service name] 
  3. Unload services that are able to be disabled in the list from step 4.

     launchctl unload [service name]
  4. Disable the startup of the items stopped in step 4 by editing the appropriate .plist file ( for info -- man launchd.plist ) and if already present, set the 'Disabled' key to true. If this key is not already in the file, add it by adding the following lines to the first block:


The first five lines from a config file on my system illustrates this:

 <?xml version="1.0" encoding="UTF-8"?>
 <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
 <plist version="1.0">
  1. Reboot the system. Better to do it the gentle way, than to issue a launchctl reboot, unless you are prepared for the brutal user session tear down which may result in lost information, unpreserved states, inconsistent file states.

I hope this helps.


  • Thanks for your <key>Disabled</key> <true/> code. I had it with a lowercase d for disabled instead of Disabled, and that mistake cause the service to start again on restart.
    – stwr667
    Jul 22, 2021 at 7:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .