Understand launchd domains

launchd starts and supervises many system and user processes. Jobs live in domains, so the same label can have meaning only within its system or user context.

There are three domains you will actually query:

• system: jobs that run as root, from boot, with no user logged in. Defined in /System/Library/LaunchDaemons and /Library/LaunchDaemons.
• user/<uid>: background jobs for one user, even without a graphical session.
• gui/<uid>: jobs tied to a user’s logged-in graphical session. Third-party agents install into ~/Library/LaunchAgents or /Library/LaunchAgents.

Inspect a domain

Inspect the current graphical user domain:

launchctl print gui/$(id -u)

The output is long. It lists the domain’s services with their labels and current state. Search for a specific label instead of reading the entire output blindly:

launchctl print gui/$(id -u)/com.example.sync

Read these fields in the output: state (running or not), path (the property list that defines the job), program or arguments (the executable it launches), and last exit code. Those four answer most “what is this thing?” questions.

Query the right domain

A daemon defined in /Library/LaunchDaemons does not appear in your gui domain. If you ask the wrong domain, launchctl reports the service as unknown and you may wrongly conclude it is not installed:

sudo launchctl print system/com.example.backupd

Note the sudo: the system domain belongs to root.

What not to do

Do not unload unknown Apple services; first identify the job owner, property list, executable, and recent exit state. Many Apple jobs restart on demand anyway, so a bootout teaches you nothing and can destabilize the session. Inspection is cheap and reversible. Removal is neither, so save it for jobs you have positively identified as yours or as third-party leftovers.