tail Command on Mac: -F Lost 49 of 60 Lines in a Rotation

I rotated a log file the way newsyslog does, by renaming it while a writer still held it open, and watched it with three followers at once. The writer kept appending to the renamed file, as an already-open descriptor does. Here is how many of its 60 lines each follower printed, over three runs on macOS 26.4.1:

/usr/bin/tail -F app.log    shown=11 of 60   (3/3 runs)
/usr/bin/tail -f app.log    shown=60 of 60
gtail -F app.log            shown=60 of 60   (GNU coreutils 9.12)

The follower everyone recommends for rotated logs, capital -F, was the only one that lost output. It switched to the new, empty file the instant the rename happened and never looked at the old one again. No error message, just a quiet terminal while 49 lines went into app.log.0.

The tail command on Mac is Apple's build from text_cmds-199 (that is what what /usr/bin/tail prints on this machine), and it differs from Linux tail in follow behavior, missing options and, until macOS 14, speed. I ran every case below on a Mac mini M4, read Apple's published source for all nine versions of the follow code, and compiled the old line-counting routine to time it against the current one.

What tail -F does on a rename

The -F loop in forward.c asks kqueue for NOTE_DELETE | NOTE_RENAME on the open file, so a rename wakes it immediately. It then reopens the name, and if the inode differs it calls show() once to drain whatever is already in the old file, closes it, and carries on with the new one. Anything written to the old inode after that moment is never read. GNU tail on macOS has no inotify, so it polls; its manual says it only re-checks the name after --max-unchanged-stats (default 5) iterations in which the file did not change. While the writer is still active, the old file keeps changing, so GNU keeps reading it, and only switches once it goes quiet.

This is exactly what happens to a launchd job that logs through StandardOutPath. As I found when testing launchd log rotation, newsyslog renames the file and the descriptor stays on the archive, so a long-running job writes into .0 until it is respawned. Follow that log with tail -F and you see the job go silent at the top of the hour. With tail -f you keep seeing it, but you will miss the next run's output, because -f never looks at the path again.

Other cases, each run on both implementations with the same script:

What happened to the file	/usr/bin/tail -F	gtail -F
Renamed, writer reopens the path	New lines shown at once	Shown, but not within 3 s; shown within 10 s
Deleted, recreated 2 s later	New lines shown, no message	Shown, "has been replaced; following new file"
Truncated with : > app.log	Continues from 0, no message	Continues, "file truncated" on stderr
Edited with sed -i '' (new inode)	Whole file printed again	Whole file printed again
Did not exist at start	Waits silently, prints it when created	"cannot open", then "has appeared"

The sed -i row catches anyone who follows a config file while editing it: in-place edits write a new file and rename it over the old one, so -F treats every save as a rotation and reprints from line 1. Plain -f on a missing file exits at once with No such file or directory and status 1.

The source history adds one more wrinkle. From Mac OS X 10.3 through 10.6 (text_cmds-30 to 71) the rename branch called freopen() without draining, so even lines already in the old file but not yet printed were skipped. The drain-then-switch logic arrived with 10.7 and is in all 97 of the 166 Apple releases from 10.7 through 26.5, across six revisions of the file.

Why tail -f | grep shows nothing

This is the most common tail complaint I found on Stack Exchange that is not about rotation: tail -f with two greps prints nothing on OS X, while cat with the same greps works. tail is not the cause. It flushes after every read. grep buffers its output when stdout is a pipe or a file. I appended three matching lines and checked after two seconds:

tail -f a.log | grep L > g1.txt                    # 0 lines after 2 s
tail -f a.log | grep --line-buffered L > g2.txt    # 3 lines

Any grep that is not last in the pipe, or whose output goes to a file, needs --line-buffered. Apple's grep supports it. For sed the matching flag is -l, and for awk you call fflush().

Options that are not there

Apple's usage line is the full list: tail [-F | -f | -r] [-q] [-b # | -c # | -n #] [file ...], plus -v. I tried eight GNU options and every one failed with status 1 and that usage text: --pid, -s, --retry, -z, --follow=name, --sleep-interval, --max-unchanged-stats and --zero-terminated. The one people miss most is --pid, which stops following when the writer exits; the Ask Different question about it has 3,363 views, and the top answer is to install coreutils and use gtail.

Going the other way, Apple's tail has things GNU's lacks:

• tail -r prints a file in reverse line order, the Mac's stand-in for tac. gtail -r fails with invalid option -- 'r'.
• Historic syntax still works: tail -3, tail +3 and tail -3r (last three lines, reversed). gtail +3 treats +3 as a file name.
• Counts take size suffixes: -n 1k printed 1,024 lines and -c 1k printed 1,024 bytes.

tail -n +2 (start at line 2, the usual way to skip a header) works the same in both. If you came here from head's "illegal line count" error, note the asymmetry: tail's +N is portable, head's negative -n -N is not.

The slow tail -n before macOS 14

An Ask Different report from Big Sur says tail -265000 on a 1 GB text file took over ten minutes while head was instant. On 26.4.1 the same request on a 520 MB, 2-million-line file took 0.149 s with Apple's tail and 0.100 s with gtail. The reason is in the source. Up to text_cmds-154 (macOS 13), Apple's rlines() stepped back one block at a time and read character by character, calling ftello() after every byte; the 13.x copy even carries a comment that rewriting it to avoid re-reading tail blocks is "likely not worth the cognitive effort." text_cmds-165.0.4, which shipped with macOS 14.0, replaced it with a plain backward scan over 4 KB blocks.

I compiled both versions of the function from Apple's source into the same test harness and ran them on the same file. Output was byte-identical every time:

Request	macOS 13 code (text_cmds-154)	macOS 14+ code (text_cmds-199)
-n 132500, 520 MB file	1.04 s	0.07 s
-n 265000	2.16 s	0.13 s
-n 1000000	6.98 s	0.52 s
-n 1000, 3,000 lines of 100 KB	2.98 s	0.18 s

That is 13 to 17 times slower and roughly linear, so it does not reproduce ten minutes by itself; the reporter's file, disk and options may account for the rest. What it does say is that a slow tail -n on macOS 13 or earlier is a known property of the binary, and macOS 14 or later, or gtail, fixes it.

Exiting, and why my agents never follow

The most common autocomplete for this topic is how to exit it. tail -f runs until it gets a signal. I drove it in a real terminal through tmux: typing q and Return did nothing, and Ctrl-C ended it with status 130. If you started it in the background, use kill %1.

That never-returning design is also why automated callers should not use it. Across 2,972 Claude Code session transcripts on this machine (excluding this one), my agents ran 16,307 Bash commands, 3,199 of which invoked tail. Not one used -f or -F. A follow inside a tool call would hold it until the timeout. When something has to be watched, the pattern is a bounded loop that checks a PID or a file and exits, the same shape as the while-loop replacements I timed for the watch command on Mac. A job left running with nohup on Mac gets checked with kill -0 PID in a loop, not followed.

FAQ

How do I exit tail -f on a Mac?

Press Ctrl-C. tail -f runs until it receives a signal, and Ctrl-C sends SIGINT, which ends it with exit status 130. Typing q does nothing, because tail is not a pager. If tail is running in the background, bring it forward with fg or stop it with kill %1. To have it stop when the process writing the file exits, install GNU coreutils and use gtail -f --pid=PID, because macOS tail has no --pid option.

Should I use tail -f or tail -F for rotated logs on macOS?

It depends on whether the writer reopens the file. If it does, tail -F follows the new file and tail -f stays on the old one. If it does not, as with a launchd job using StandardOutPath after newsyslog renames the log, macOS tail -F switches to the new empty file at the rename and misses everything the job keeps writing to the archive, while tail -f keeps showing it. GNU gtail -F reads the old file until it stops changing, then switches, which handles both cases.

Why does tail -f piped to grep show no output on Mac?

grep buffers its output when it writes to a pipe or a file, so matches sit in a buffer instead of appearing. tail itself flushes after each read. Add --line-buffered to every grep that is not writing straight to the terminal, for example tail -f app.log | grep --line-buffered ERROR | grep -v DEBUG.

How this was checked: every follow test ran on 2026-10-16 on a Mac mini M4 with macOS 26.4.1, comparing /usr/bin/tail (text_cmds-199, per what(1)) with Homebrew's gtail from GNU coreutils 9.12, in throwaway directories under /tmp. The rotation test used a bash writer holding the file open with exec 3>> and appending a line, then sleeping 0.1 s, 60 times, a rename about two seconds in, and three runs per follower; the timings depend on that pacing. The release mapping joins Apple's text_cmds tags with the distribution-macOS tags (166 releases, 10.0 to 26.5) by commit, then compares the git blob of tail/forward.c in each. The speed table comes from rlines() extracted verbatim from text_cmds-154 and text_cmds-199 and compiled with cc -O2 into a 10-line harness, so it measures the algorithm, not a real macOS 13 system. The transcript counts are a regex over Bash tool calls in this machine's Claude Code transcripts and can miss unusual forms. Stack Exchange view counts were read from the Stack Exchange API the same day.