Connect launchd state to logs

A background process that disappears may have exited normally, crashed, been throttled, or failed before launch. Each of those leaves a different trail, and launchd plus the unified log together tell you which one happened.

Inspect the owning launchd domain and exact label first. Guessing at the label wastes time; find it in the job’s property list or with launchctl print gui/$(id -u) and a search.

Read the job state

Capture launchctl print output for the job:

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

Four fields carry most of the diagnosis. state tells you whether it is running now. path points at the property list that defines it. program (or the arguments array) is the executable launchd tries to run. last exit code is the punchline: 0 means the last run ended normally, a non-zero value means the program reported failure, and a line mentioning a signal means it was killed or crashed.

Compare the executable path with the expected installation. A job whose program points at /usr/local/bin/sync-agent after you moved the tool to /opt/homebrew/bin will fail before launch, forever, with no output of its own.

Match the log events

Then query recent logs for its process or subsystem:

log show --last 30m --style compact \
  --predicate 'process == "sync-agent"'

Line up log timestamps with the exit state you just captured. A crash shows the process starting and dying repeatedly. A throttled job shows launchd complaining about respawning too fast. A path problem shows launchd erroring at spawn time with no process events at all.

Preserve before restarting

Do not repeatedly kickstart the job before saving exit state and logs. Restarts can erase timing and create a new symptom. Every launchctl kickstart -k resets last exit code and muddies the timeline, so capture both outputs to a file first, then experiment.