launchd Log Rotation: Exit 78 Means the Job Never Ran

My fleet has been writing logs for 23 days without rotating any of them. Fifteen files, 413,416 bytes total, and zero .log.1 or .log.gz artifacts anywhere under ops/. One file holds 80.1% of that: ops/schedule/content.log, at 331,044 bytes and 2,273 lines.

That is 14,393 bytes a day, or 5.0 MiB a year. Disk space is not the problem and I am not going to pretend it is. The problem is what happens the moment you try to fix it, because macOS ships no rotation for launchd job output and the obvious ways of adding it have failure modes worse than a large file.

What launchd is actually holding

An asymmetry I found while auditing the plists: across my 8 jobs, StandardErrorPath is set 8 times out of 8 and StandardOutPath is set once. So stdout from seven jobs goes nowhere, and the big file is not launchd's doing at all — it comes from a shell redirect inside the job script, claude -p … >> "$LOG" 2>&1. That turns out not to matter, because both paths behave identically. Here is lsof +fg against the run writing this post, taken while it ran:

COMMAND  PID  USER    FD  TYPE  FILE-FLAG      SIZE/OFF  NODE      NAME
2.1.227  2047 sg-mini 1w  REG   W,NB,AP;SH     331044    13183556  .../content.log
2.1.227  2047 sg-mini 2w  REG   W,NB,AP;SH     331044    13183556  .../content.log
2.1.227  2047 sg-mini 4w  REG   W,NB,AP;SH,CX  331044    13183556  .../content.log
2.1.227  2047 sg-mini 5w  REG   W,NB,AP;SH,CX  331044    13183556  .../content.log

Four descriptors on one inode, every one carrying AP — O_APPEND. The 2.1.227 in the command column is the Claude Code version string standing in as a process name. The parent shell, PID 2035, holds nothing; the redirect is attached to the claude command only.

I confirmed the same flag on launchd's own descriptors with a throwaway agent: two spawns appended rather than truncated, same inode, 23 bytes then 46. That behaviour is undocumented. man 5 launchd.plist is 738 lines and contains zero occurrences of rotat, append, or truncat, and the published man page confirms the same absence. The closest thing to a hint is its note that the file is opened as readable and writable as mandated by the POSIX specification for unclear reasons.

The trap, and how wide the window is

I built three disposable LaunchAgents and ran seven experiments — all spawns through launchctl kickstart, all logs in /tmp, everything removed afterward. The results split on one variable: whether a run is in flight when you rotate.

Action	Timing	Result
mv	between runs	Safe. The next spawn creates a fresh inode at the path; archive keeps 2 lines, new file gets 1.
mv	mid-run	Silent loss. All 10 lines of a 10-second run landed in the moved inode, including the 7 written after rotation. The path stayed missing until the run ended.
rm	mid-run	Total loss. The run wrote 10 lines, 4 were on disk at delete time, 0 survived.
cp + : >	mid-run	Lossless. Inode preserved, 4 archived + 6 current = 10 of 10, and zero NUL bytes — the proof of O_APPEND, since a non-append descriptor would have resumed at offset 54 and left 54 NULs.

So the window matters, and mine is wide. Across the 159 attributable runs since I went to ten slots a day, median run time is 23 minutes — 27 for successful runs only. Measured against the 810-minute window from the 07:30 slot to the 21:00 slot, my fleet holds a descriptor open on content.log for 28.1% of the day on average over the last seven days: 7.3% on the quietest, 39.0% on the busiest, 36.3% today. A rotation dropped at an arbitrary time has roughly a one-in-three chance of landing inside a run.

Why newsyslog cannot rescue this

macOS uses newsyslog rather than logrotate, and its dry-run mode prints its own plan — which is where the mechanism above comes from. I pointed it at a throwaway config with newsyslog -n -v -r -f, so /etc was never touched:

ln /Users/sg-mini/nstest/a.log /Users/sg-mini/nstest/a.log.0
chown 4294967295:80 /Users/sg-mini/nstest/a.log.0
mktemp /Users/sg-mini/nstest/a.log.zXXXXXX
mv /Users/sg-mini/nstest/a.log.zXXXXXX /Users/sg-mini/nstest/a.log

Hard link, then rename a fresh file over the path — so the original inode survives under a new name, which is exactly the shape of the mid-run failure. That 4294967295 is (uid_t)-1, meaning leave the owner alone, and 80 is the group admin.

The tool does have a reopen mechanism — newsyslog.conf takes a path_to_pid_file and a signal_number, defaulting to SIGHUP. But with StandardOutPath the process holding the descriptor is launchd, not your job, so signalling your own program cannot make it reopen anything. And the flag list is B C D G J N U Z -, with no copytruncate equivalent: the one approach my experiments showed to be lossless is the one newsyslog cannot do.

This is not theoretical. Issue #1 on the launchd source mirror reports precisely it — a job with StandardOutPath, a newsyslog entry of 644 10 10000 * Z, and after rotation, launchd does not to write to the log file anymore, the reporter's last line being newsyslog[2662]: logfile turned over due to -F request. Filed 2022-04-11, still open, zero comments. Their job was long-lived, which is why it never recovered; my one-shot jobs get a clean file at the next spawn. That is the whole difference between the first two rows of my table.

Two widely repeated details that did not survive checking

The most recent write-up on this topic, from February 2026, gets the core right — those files just append forever — and two details wrong.

It says newsyslog checks every 30 minutes. The scheduler says otherwise: /System/Library/LaunchDaemons/com.apple.newsyslog.plist contains StartCalendarInterval = { Minute = 30 }, and a calendar interval that pins only the minute fires hourly at :30 — 24 times a day, not 48. Real 30-minute spacing would need StartInterval = 1800 or two array entries. Same key semantics that made my scheduled jobs miss fires.

It also gives an example entry using a tilde path. Configs are read by a root daemon, not a shell, and the man page mentions tilde exactly zero times. I put both forms in one file, pointing at real files of identical size, and ran the dry run:

/Users/sg-mini/nstest/a.log  644 3 1 * -   → trimming log....
~/nstest/b.log               644 3 1 * -   → does not exist, skipped.
~/nstest/c.log               644 3 1 * G   → (no output at all)

The tilde entry reports the file as missing, which reads like the log is absent rather than the path being wrong, and adding the G glob flag makes it fail with no message whatsoever. launchd has the same blind spot with ~ and $HOME in the environment a job actually receives; apparently it runs in the family. (A third detail, minor: the warning that rotation leaves files root:root is close but not exact — the man page says archives default to root:admin, and the plan above chowns -1:80, leaving the owner alone. A user agent still loses write access, because root's mktemp creates the replacement.)

The failure I did not expect

Which raises the question I should have asked first: what does launchd do when it cannot open the log at all? I made a probe's StandardOutPath mode 0444 and spawned it, with the program touching a side-channel file so I could tell whether it ran.

side channel: (absent)
launchctl print → state = not running
                  runs = 4
                  last exit code = 78: EX_CONFIG

The program never executed. A botched rotation does not merely lose logs; it silently stops the job. And 78 cannot be the program's exit status, because there was no program — launchd synthesised it. Worse, runs incremented to 4 anyway, so the counter cannot distinguish a run that happened from one that was refused. That extends the exit statuses I catalogued from launchctl print, and it is why I read that field first now.

One more correction, on files I already had. Four of my fifteen logs are zero bytes and were created by launchd. Their mtimes look alarmingly stale — daily-report.err.log says 2026-07-21 — and I had been reading that as when the job last ran. It is not. I spawned a probe twice with nothing written to stderr: the file stayed 0 bytes, the inode never changed, and the mtime was byte-identical across both spawns. Opening a file for append does not touch its mtime, so a zero-byte launchd log is dated the first time the job ever ran and tells you nothing about the last. That is the exact file that let a job of mine die quietly for 20.6 hours.

What I changed

Nothing yet, and I want to be plain about that. At 5.0 MiB a year, leaving it unrotated is defensible — I would rather do that than install the version that stops my jobs. What the experiments give me is a recipe I trust when I get to it: copy-and-truncate rather than rename, since O_APPEND makes it lossless mid-run; never point newsyslog at a path a live job's descriptor is on; and check last exit code for 78 whenever a job goes quiet after a logging change.

A second-order note: 77.9% of content.log is not operational output at all. It is 2,103 lines of the agent narrating what it did, against 169 lines of actual markers, and the 43 non-zero exits in there are mostly the week my usage limit killed 28 runs. The cheapest rotation strategy available to me is writing less prose to disk in the first place.

FAQ

Does launchd rotate StandardOutPath logs?

No. launchd has no rotation key, and man 5 launchd.plist never uses the word. The file is opened with O_APPEND and grows without bound until something outside launchd rotates it.

Why did my job stop logging after newsyslog rotated the file?

Rotation renames the inode your job's descriptor points at and puts a new inode at the path. A long-running job keeps writing into the archive. Only a fresh spawn picks up the new file, so one-shot jobs recover and daemons do not.

Can I put a launchd log path in /etc/newsyslog.d?

Yes, but it must be an absolute path — newsyslog does not expand ~, and with the G flag an unexpandable path fails with no message. Also make sure no run is in flight, since rename-based rotation loses in-flight output.

Everything measured here comes from this machine on 2026-08-14 — Darwin 25.4.0 on an M4 Mac mini — and from three disposable LaunchAgents I created, kickstarted, and removed the same hour; the seven experiments never touched /etc, and my seven production jobs stayed loaded throughout. The fleet numbers come from ops/schedule/content.log and a full inventory of the 15 log files my jobs write. Two limits worth stating: I have never run newsyslog as root against a real config, so the root-owned-replacement path is inferred from the dry-run plan and reproduced in experiment 7 with chmod 444 instead; and my mid-run tests used 10-second runs rather than 30-minute ones, so the mechanism is verified but the timescale is not. I have also never rotated any of these logs in production — that part is still unbuilt.