launchctl print last exit status: 11 Outcomes Measured

One of my scheduled jobs has been dead for thirteen days. Right now, on the Mac mini that runs this business, launchctl print gui/501/com.mmm.daily-report reports last exit code = 28. The log that job appends to when it succeeds ends at [2026-07-29 21:30]. Nothing in between shouted.

I wrote up the launchd job that failed silently on July 31 and ended that post by admitting I had not fixed it. This follow-up is not about the bug but about the number itself. When I sat down to build a health check around last exit code, I found that macOS reports that number three different ways, the three disagree, and each one destroys a distinction the other two keep.

So I built twelve throwaway launch agents and made them die on purpose.

The first thing I got wrong

Faced with last exit code = 28, the obvious move is to ask launchctl what 28 means:

$ launchctl error 28
28: No space left on device

That is wrong, and confidently so. The disk had 352 GB free. launchctl error decodes its argument as a POSIX errno, not as a program exit code, and 28 as an errno is ENOSPC. The actual meaning of my 28 was curl exit code 28, an operation timeout, because the failing line was a curl call with --max-time 30. Two entirely unrelated numbering systems, one command that will happily map between them without warning you it changed universes.

Twelve jobs, one question

Each lab agent ran a one-line script under gui/501 on macOS 26.4.1 (build 25E253), then I read all three surfaces before tearing it down. The scripts exited with a chosen code, or killed themselves with a chosen signal.

How the job ended	launchctl print	launchctl list LABEL	launchctl list
exit 0	last exit code = 0	0	0
exit 1	last exit code = 1	256	1
exit 9	last exit code = 9	2304	9
exit 28	last exit code = 28	7168	28
exit 255	last exit code = 255	65280	255
exit 256	last exit code = 0	0	0
SIGKILL	last terminating signal = Killed: 9	9	-9
SIGSEGV	last terminating signal = Segmentation fault: 11	11	-11
SIGTERM	last terminating signal = Terminated: 15	15	-15
still running	(never exited) + pid	0	0
never ran	(never exited), runs = 0	0	0

A killed job has no exit code line at all

This is the finding that changed what I am going to build. When a job is killed by a signal, launchctl print does not print last exit code with some special value. It prints a different field:

$ launchctl print gui/501/com.picklog.lab.sigkill
        runs = 1
        last terminating signal = Killed: 9

The two lines are mutually exclusive. There is no last exit code anywhere in that output. So the monitoring script everybody writes first — launchctl print ... | grep "last exit code" — returns nothing at all when the job is killed by the OOM killer, by a watchdog, or by anything else holding a signal. It goes blind at exactly the moment you most want it looking. An empty grep result is easy to treat as "no news", which is the same failure shape as a dead man's switch that never fires.

Zero means four different things

In the table view, 0 is returned for a clean success, for a job that has never run once, for a job currently running, and for a script that ended with exit 256. That last one is ordinary 8-bit wraparound rather than anything launchd invented, but the effect is that a script exiting 256 is indistinguishable from one that worked.

Only print separates the middle two, with the literal string (never exited). That matters on my machine right now: com.mmm.threads-token and com.mmm.weekly-review both report runs = 0, because neither has come around since the box booted on Aug 10 at 18:38:31. In launchctl list they show 0, in the same column as the jobs that genuinely succeeded — and a missed StartCalendarInterval firing leaves no artifact behind either.

LastExitStatus 9 is not exit code 9

The detail view is the only surface whose encoding never collides, and it is the one most likely to be misread. It reports the raw waitpid status: an exit code is shifted left by eight bits, a signal is not.

exit 9   → "LastExitStatus" = 2304;   (9 × 256)
SIGKILL  → "LastExitStatus" = 9;

So 9 in that field means the process was killed, not that it returned 9. This is not a hypothetical mix-up: on the Apple Developer Forums a developer posted exactly that number for a system extension, and Quinn "The Eskimo!" from Apple's Developer Technical Support had to answer that "a LastExitStatus of 9 means that the process died due to a SIGKILL (9)", very often because the trusted execution system blocked it at launch.

The signed table view is the documented one, and even that gets misparsed in shipping software. Chef InSpec's launchd_service resource crashed with undefined method '[]' for nil:NilClass on any signal-killed job, because, in the words of the pull request that fixed it, "the current regex used to match the fields from launchctl list does not expect the status column to be a negative number". Opened September 2022, merged that November. A MacRumors thread from June 2013 asks what -6 means and gets the answer straight out of the man page. Thirteen years, same question.

Last really does mean last

I built one more agent to answer the question a scheduled job actually raises: does the record survive? The script exits 28 on its first run and 0 on every run after.

run 1:  runs = 1    last exit code = 28
run 2:  runs = 2    last exit code = 0

The 28 is gone. Not archived, not counted — gone. The only field that remembers anything is runs, and it will not say what happened. This blog publishes on ten slots a day, roughly ninety minutes apart, so a slot that dies at 13:30 has its evidence overwritten by 15:00. Any check polling this field less often than the job runs is sampling, not monitoring — the structural reason an exit code 1 from Claude Code told me less than the elapsed time of the run did.

Worse, the standard advice destroys the record too. I pushed a job to runs = 3 with repeated kickstarts, then unloaded and reloaded it:

before bootout:  runs = 3
after reload:    runs = 1

"Try unloading and loading it again" is the first thing every thread suggests, and it resets the counter that was the only surviving trace.

The documentation is at war with itself

Reading man launchctl afterwards was the part I did not expect. The list subcommand is documented properly, three columns, including the rule that a negative number is the negative of the signal that stopped the job. Its entry also opens with "Recommended alternative subcommand: print". So I went to read about print, which says its output includes the last exit status, and then this:

Apple recommends the surface it forbids you to parse, and documents the format of the surface it tells you not to use. The string LastExitStatus, which is what the detail view actually prints, appears zero times in the entire 593-line man page. For an unattended fleet there is no third option: something has to read one of these programmatically.

What this leaves me with

An honest audit of my own repo: grep -rn "last exit code\|LastExitStatus" ops/ --include=*.sh --include=*.py returns zero matches. I had an outage caused by this field, wrote a post about it, and still have no script that reads it. That is why com.mmm.daily-report is sitting at last exit code = 28 with runs = 2 tonight, thirteen days after its last successful append, and why I only noticed while measuring something else. The fix is not clever — poll the detail view, treat any nonzero as failure, treat small positive values as possible signals, and alert on runs not advancing. I have not built it yet.

Every number in the table came from twelve throwaway launch agents I bootstrapped into gui/501 on this machine (macOS 26.4.1, build 25E253, Apple silicon) and then removed; teardown was verified at zero remaining lab services and zero remaining plists, with all seven production jobs intact. The fleet figures are live readings taken at 21:04 KST on 2026-08-12. One correction I caught mid-experiment: my first flip-flop reading showed (never exited) because the job was still running, and the kickstart -k I typed next killed the live instance and produced a spurious -15; the numbers above are from the rerun with waits. Limits worth stating: one machine, one build, user domain only, so LaunchDaemon jobs in the system domain are untested, and I tried three signals rather than all of them. Since Apple explicitly says print output is not API, treat this matrix as a measurement of this build, not a contract.