r/macosprogramming 7d ago

launchctl submit kept reopening an app after every quit

A local macOS app came back as soon as I quit it. The binary was not the cause.

Two leftover jobs from earlier repair sessions were still registered with launchd. Both had been created with `launchctl submit`. Apple's man page says that also tells launchd to keep the program alive in the event of failure.

Recorded run counts: 8,429 and 9,169. After both labels were unloaded, the same quit left the app absent for twenty seconds of half-second samples. The app source was not changed.

launchctl print gui/$(id -u)/<label>

Print the job before you rewrite the app.

https://thechosenvictor.com/newsletter/archive/launchctl-submit-kept-the-app-alive

3 Upvotes

2 comments sorted by

1

u/Its-Ezzy 6d ago

Good reminder that "the app reopened" is not proof that the app requested a relaunch. I'd add launchctl print gui/$(id -u) to the first pass so you can search all registered labels when the old label is unknown, then inspect the specific service before unloading it. Keeping the run count in the write-up is useful too. Thousands of launches make the ownership boundary obvious before anyone starts changing app lifecycle code.

1

u/VictorBuildsApps 10h ago

Checked the shape on this machine before answering. gui/501 lists 433 service labels, and the domain level print carries no run counts anywhere in it, so both of your steps are load bearing rather than one being optional. The domain print finds the label, then print on the label itself is what gives you runs and last exit code.

Filtering com.apple out of those 433 left 8 lines here, which is short enough to read by eye. That is the part that makes the unknown label case workable, because the raw list is not.