Linux command: tail

Something is wrong on a server, and the first thing anybody types is tail -f on a log file. It is probably the most-used command in system administration, and almost everybody uses it in a way that will silently stop working at midnight tonight, when the log rotates. This article is about the ten-line default, the plus sign that changes what the number means, and the one letter that decides whether you are still watching your log tomorrow morning.

2. Where the Names Come From

The names are literal. A file has a head and a tail the way a queue or a list does, and the commands print one or the other. There is no acronym and no hidden joke.

What is worth knowing is the asymmetry underneath. These two look like siblings written together, and they were not. They come from different Unix lineages, they arrived a year apart, and only one of them ever grew the feature that made it famous. tail got -f. head never needed it: a file does not grow at the front.

That one option is the reason tail is a household name and head is not. The vocabulary around it is small and worth having straight:

-f, --follow      keep the file open and print new data as it is appended
-F                shorthand for --follow=name --retry (see section 6)
descriptor        follow THIS file, even if it gets renamed  (the -f default)
name              follow whatever has THIS name, reopening as needed
--retry           keep trying to open a file that is missing or unreadable
rotation          when a log is renamed or truncated and a fresh one begins
inotify           the kernel interface that tells tail the moment a file changes

Two of those matter more than the rest. Descriptor versus name is the whole of section 6, and it is the difference between a tail -f that survives the night and one that does not. And inotify is why modern tail -f reacts instantly instead of waking up once a second to look.

4. Simple Use Cases

4.1 Looking at the Ends of Things

The everyday uses need no explanation, only the habit:

$ head -n 20 /etc/services              # what is at the top of this file?
$ tail -n 50 /var/log/nginx/error.log   # what just went wrong?
$ head -n 1 *.csv                       # the header row of every file
$ tail -n 1 /etc/passwd                 # the most recently added account

4.2 Skipping a Header Row

This is the single most useful thing the plus sign does, and it comes up constantly with CSV files and with commands that print a title line:

$ tail -n +2 data.csv                   # everything EXCEPT the header
$ ps aux | tail -n +2                   # the processes, without the column titles
$ df -h | tail -n +2 | sort -k5 -hr     # sort by use%, header out of the way

Read -n +2 as "start at line 2". It is the idiomatic way to drop a header in a shell pipeline, and it is much safer than grep -v against the header text, which will also delete any data row that happens to match.

4.3 Several Files at Once

Give either command more than one file and it labels them for you:

$ tail -n 1 f1.txt f2.txt
==> f1.txt <==
a2

==> f2.txt <==
b2

Two options control those labels, and both are occasionally exactly what you need:

$ tail -q -n 1 f1.txt f2.txt        # -q for quiet: no headers, just the lines
a2
b2

$ tail -v -n 1 f1.txt               # -v for verbose: force a header on ONE file
==> f1.txt <==
a2

-q is the one you want when you are feeding the result into another command, because those ==> lines are data as far as the next program is concerned. A quick way to get the last line of every log in a directory:

$ tail -q -n 1 /var/log/*.log | sort

4.4 Bytes Instead of Lines

-c is the right tool when the file has no useful lines, or when you care about size rather than structure:

$ head -c 512 disk.img | xxd | head -n 4     # look at a boot sector
$ head -c 2M huge.log > sample.log           # grab a manageable sample
$ tail -c 100 file.bin | xxd                 # the last 100 bytes

head -c is the polite way to sample a very large or binary file, because it stops reading as soon as it has what it needs. Section 7.1 measures exactly how much that saves.

One caution on text. Bytes are not characters, and -c counts bytes. Cut in the wrong place and you slice a multibyte character in half:

$ printf 'aeiou \xc3\xa9\xc3\xa8\xc3\xaa done\n' > u.txt      # three 2-byte chars

$ tail -c 12 u.txt | xxd
00000000: c3a9 c3a8 c3aa 2064 6f6e 650a       # lands on a boundary: fine

$ tail -c 11 u.txt | xxd
00000000: a9c3 a8c3 aa20 646f 6e65 0a         # starts mid-character

$ tail -c 11 u.txt | iconv -f UTF-8 -t UTF-8
iconv: illegal input sequence at position 0

A lone continuation byte is not valid UTF-8, so the first character comes out as a replacement glyph or as nothing at all. For anything with accents, emoji or non-Latin text, count lines rather than bytes.

6. Advanced Use Cases

6.1 Log Rotation, and the Letter That Matters

This is the most important section in the article. Every log on a production server is rotated, usually nightly, and the default tail -f does not survive it. It does not warn you. It just stops showing you anything, forever, while looking exactly like it is working.

Here is the experiment. Two tails on the same file, one with -f and one with -F, across a rename-and-recreate rotation:

$ echo "line 1 before rotation" > app.log
$ tail -f app.log > out-f.txt &
$ tail -F app.log > out-F.txt &
$ echo "line 2 before rotation" >> app.log

$ mv app.log app.log.1                     # what logrotate does
$ echo "line 3 AFTER rotation" > app.log
$ echo "line 4 AFTER rotation" >> app.log

And the two results, side by side:

----- tail -f saw -----
line 1 before rotation
line 2 before rotation
                                   # and then nothing. Ever.

----- tail -F saw -----
line 1 before rotation
line 2 before rotation
tail: 'app.log' has become inaccessible: No such file or directory
tail: 'app.log' has appeared;  following new file
line 3 AFTER rotation
line 4 AFTER rotation

The reason is a piece of Unix that is worth understanding once, because it explains a dozen other things too. A filename is not a file. Three separate layers are involved:

So when logrotate renames app.log to app.log.1, nothing happens to the file tail has open. The directory entry moved; the inode did not. tail -f is still faithfully following the same bytes it always was, which are now called app.log.1 and which nothing will ever write to again.

That is the whole bug, and it is a fair design rather than a mistake. -f follows the file descriptor, which is correct for "watch this exact file" and exactly wrong for "watch this log".

-F follows the name. When the name stops pointing at the file it had open, it says so and reopens. It is shorthand for two longer options:

$ tail -F app.log
$ tail --follow=name --retry app.log       # identical

Make -F your default for anything under /var/log. There is no cost: on a file that never rotates, -F behaves exactly like -f.

6.2 The Other Kind of Rotation

The rule above needs one honest qualification, because logrotate has a second mode. With copytruncate, the file is copied and then emptied in place rather than renamed, so the descriptor stays valid. Plain -f handles that case:

$ cp t.log t.log.1 && : > t.log        # copytruncate, in two commands
$ echo "after truncate" >> t.log

# what tail -f printed:
before 1
before 2
tail: t.log: file truncated
after truncate                     # it kept up

So which rotation style your server uses decides whether plain -f quietly fails. You can look:

$ grep -r copytruncate /etc/logrotate.conf /etc/logrotate.d/ | head

The practical advice does not change. Use -F and you do not have to know or care, because it copes with both.

6.3 Waiting for a File That Does Not Exist Yet

-F includes --retry, which means you can start watching before there is anything to watch. This is exactly what you want when you are about to start a service and its log does not exist until it does:

$ tail -F /var/log/myapp/app.log
tail: cannot open '/var/log/myapp/app.log' for reading: No such file or directory
tail: '/var/log/myapp/app.log' has appeared;  following new file
[2026-08-24 09:15:02] starting up

Plain tail -f on a missing file prints an error and exits immediately. -F waits. Start the tail first, then start the service, and you will not miss the first lines.

6.4 inotify, and What -s Is Still For

Modern tail -f does not poll. On Linux it asks the kernel to tell it when the file changes, using the same inotify interface that other file-watching tools use. You can confirm it on a running tail:

$ tail -f w.log &
$ ls -l /proc/$!/fd | grep -c inotify
1                                  # one inotify descriptor

That is why new lines appear instantly rather than up to a second later. The -s option, which sets a sleep interval between checks, is a leftover from the polling era and does almost nothing on a local file today. It still matters in one case: inotify does not work reliably on network filesystems, so on an NFS-mounted log tail falls back to polling and -s becomes real again.

$ tail -f -s 5 /mnt/nfs/shared/app.log     # check every 5s on a network mount

6.5 In Scripts

head and tail are well behaved in scripts as long as you avoid -f, which by design never returns. Three patterns cover almost everything:

# bounded: read a fixed amount and move on
last_line=$(tail -n 1 "$logfile")

# follow, but with an owner: tail dies when the job does
./deploy.sh & tail -F deploy.log --pid=$!

# follow, but with a deadline
timeout 300 tail -F deploy.log

Watch out for one interaction. If you write tail -f log | grep -q PATTERN expecting it to exit on the first match, remember that grep -q does exit, but tail may not notice until it next tries to write, so the pipeline can hang. Give it a deadline with timeout, or use the --pid form above.

There is a second interaction, and this one has broken more scripts than anything else in this article. Section 7.2 shows that head kills its producer with SIGPIPE, giving it exit code 141. Normally the shell hides that, because a pipeline reports only the status of its last command. Turn on pipefail and it stops hiding it:

$ bash -c 'yes | head -n 2 >/dev/null; echo $?'
0                                  # the usual, comfortable answer

$ bash -c 'set -o pipefail; yes | head -n 2 >/dev/null; echo $?'
141                                # SIGPIPE, now visible

Now consider how nearly every careful script begins:

#!/bin/bash
set -euo pipefail                  # the standard safety boilerplate

count=$(seq 1 2000000 | head -n 1)        # perfectly ordinary line
echo "reached this line, c=$count"        # never printed

$ ./script.sh; echo "script exit: $?"
script exit: 141

set -e saw a non-zero status and stopped. The pipeline did exactly what it was supposed to do, and the script died without a message. This catches people who have done everything right. Three ways out, measured:

seq 1 2000000 | head -n 1        -> 141    the problem
seq 1 2000000 | head -n 1 || true ->   0    tolerate it where it is harmless
seq 1 2000000 | sed -n '1p'      ->   0    sed keeps reading, so no SIGPIPE
seq 1 2000000 | sed -n '1{p;q}'  -> 141    ... but quit early and it is back

That third line has a cost worth naming: sed -n '1p' avoids the signal precisely because it reads all two million lines instead of stopping. It trades a status code for the work head was saving you. On a big input, || true is the better answer.

The same applies to grep -q and to anything else that closes a pipe before its producer has finished.

8. Best Practices

• Use -F, not -f, on anything in /var/log. Rename-based rotation makes plain -f go silently deaf, and -F costs nothing on a file that never rotates.
• Write -n 20, not -20. The bare number is the obsolete pre-POSIX form. It still works and it will still confuse the next reader about lines versus bytes.
• Learn tail -n +2. "Start at line 2" is the clean way to drop a header row, and it beats grep -v against the header text, which also eats matching data.
• Remember head -n -1. "Everything except the last line" saves reaching for sed whenever a file has a trailing total or summary.
• Pass the filename, do not cat into it. tail -n 5 file seeks to the end; cat file | tail -n 5 reads the whole thing. On a gigabyte log that is 0.00s against 0.32s.
• Add --line-buffered to grep in any tail -f pipeline, and -u to sed, fflush() to awk, or stdbuf -oL to anything else. Otherwise your matches sit in a 4 KB buffer.
• Start with more context than the default. tail -n 100 -F shows you what led up to the thing you are waiting for; ten lines rarely does.
• Use --pid=$! when following a job's log. The tail then ends when the job does, instead of hanging around forever.
• Never put a bare tail -f in a script. It does not return by design. Bound it with --pid or timeout.
• Use -q when feeding multiple files onward. Those ==> header lines are data to the next command in the pipeline.
• Reach for less +F when you will want to read as well as watch. Ctrl-C to scroll back and search, F to resume following.
• Prefer tail -n +8 | head -n 5 over head -n 12 | tail -n 5 for a middle range. Same answer, and it stops reading once it has what it needs.
• Guard | head in any script with set -o pipefail. Write | head -n 1 || true where the SIGPIPE is harmless, or the script dies at exit 141 having done nothing wrong.
• Count lines, not bytes, on text with accents. -c can cut a UTF-8 character in half and produce invalid output.
• Use the runtime's own command inside containers. docker logs -f --tail 100 and kubectl logs -f are the real equivalents, because a good image logs to stdout and has no file to tail.
• Read the manual for the two you will forget. --retry and --follow=name are what -F is made of, and knowing that makes its behaviour obvious rather than magical.

$ man 1 tail               # short, and the -f/-F explanation is worth reading
$ man 1 head
$ info coreutils 'tail invocation'    # deeper than the man page
$ man 1 less               # for +F
$ man 5 logrotate.conf     # to see which rotation style your server uses

10. Summary

head and tail are among the first commands anybody learns and among the last anybody reads the manual for. The parts worth knowing are the plus sign, the letter F, and the buffer in the middle of your pipeline.

• Both default to ten lines. -n changes the count, -c switches to bytes, and both read standard input when given no file.
• The sign changes the question. tail -n 3 is "the last three"; tail -n +3 is "from line 3 to the end". head -n -3 is "everything except the last three".
• tail -n +2 drops a header row. head -n -1 drops a trailing summary. Those two cover most of what people write sed for.
• tail -f dies silently when a log rotates. It follows the file descriptor, so it ends up watching the renamed old file. -F follows the name, says what happened, and reopens.
• -F is exactly --follow=name --retry, which also means it will wait for a file that does not exist yet.
• The exception: with copytruncate rotation the descriptor stays valid, so plain -f copes and prints "file truncated". Use -F and you never need to know which style your server uses.
• tail -f | grep appears broken because grep buffers. Add --line-buffered, or stdbuf -oL for anything else in the pipeline.
• tail seeks: 0.00s to read the end of a 1.1 GB file. cat file | tail reads all of it, because a pipe cannot be seeked. Pass the filename.
• head closing a pipe sends SIGPIPE to the producer, which exits 141. That is what makes yes | head stop rather than run forever.
• On Linux tail -f uses inotify and reacts instantly. -s is a polling-era option that only matters on network filesystems.
• --pid=$! makes a follow end when the job it is watching ends. Never put a bare tail -f in a script.
• Multiple files get ==> headers, including while following. -q removes them, -v forces them.
• A file with no final newline produces output with no final newline. tail copies what is there.
• head is from 1BSD in 1978 and tail from Version 7 Unix in 1979. Write -n 5, not -5: the bare number predates POSIX.
• The seek is visible in four system calls: SEEK_END for the size, SEEK_SET to a block from the end, one read of 2751 bytes out of 1.3 MB. Through a pipe there are no seeks at all, so tail falls back to a rolling buffer and reads every byte.
• A filename is not a file. Renaming moves a directory entry; the inode and any open descriptor are untouched. That is exactly why tail -f keeps reading a log nothing writes to any more.
• Under set -o pipefail, | head makes a pipeline report 141, and set -e then aborts the script. Use || true where the SIGPIPE is harmless.
• -F works on BusyBox too. --pid, --retry and the long options are GNU-only, which matters inside minimal container images.
• -c counts bytes, so it can split a UTF-8 character and produce invalid output. Count lines on text with accents.
• In containers, use docker logs -f or kubectl logs -f. And tail -f /dev/null is not logging: it is a keep-alive hack that hides the fact the container has no real main process.
• For reading as well as watching, less +F beats tail -f. For the journal, journalctl -f.

This is the quick reference worth keeping:

THE BASICS (both default to 10 lines)
head -n 20 FILE            first 20 lines
tail -n 20 FILE            last 20 lines
head -c 512 FILE           first 512 bytes  (K=1024, kB=1000)
tail -c 100 FILE           last 100 bytes

THE SIGN CHANGES THE QUESTION
tail -n +2 FILE            from line 2 on   <- drops a header row
head -n -1 FILE            all but the last line  <- drops a summary row
tail -c +2 FILE            from byte 2 on   <- strips a leading byte
head -c -4 FILE            all but the last 4 bytes

A RANGE IN THE MIDDLE (lines 8-12)
tail -n +8 FILE | head -n 5      preferred: stops reading early
head -n 12 FILE | tail -n 5      same answer, reads more

FOLLOWING A LOG
tail -F FILE               USE THIS. = --follow=name --retry
tail -f FILE               follows the descriptor: DIES on rotation
tail -n 100 -F FILE        start with real context
tail -F a.log b.log        several at once, with ==> headers
tail -F FILE --pid=$!      exit when the writer exits
timeout 300 tail -F FILE   exit after 5 minutes
less +F FILE               follow, Ctrl-C to scroll back, F to resume

UNBUFFERING A FOLLOW PIPELINE (or nothing appears)
tail -F log | grep --line-buffered ERROR
tail -F log | sed -u 's/x/y/'
tail -F log | awk '/E/ { print; fflush() }'
tail -F log | stdbuf -oL ANY-OTHER-COMMAND

MULTIPLE FILES
tail -q -n 1 *.log         no ==> headers (use when piping onward)
tail -v -n 1 one.log       force a header on a single file

IN CONTAINERS (a good image logs to stdout, so there is no file)
docker logs -f --tail 100 NAME
docker compose logs -f SERVICE
kubectl logs -f deploy/NAME --tail=100
tail -f /dev/null          NOT logging: a keep-alive hack. Prefer sleep infinity.

PORTABILITY
-n -c -q -v -f -F -s -n +N -n -N     GNU and BusyBox both
--pid --retry --follow=name          GNU only (absent in BusyBox)

SCRIPTS
set -o pipefail  +  | head   ->  exit 141, and set -e aborts. Use || true.
tail -c N on UTF-8 text can split a character. Count lines instead.

tail SEEKS to the end: pass the filename, never cat into it
exit 141 from a producer = SIGPIPE = head closed the pipe. Normal.
-5 is the obsolete pre-POSIX form. Write -n 5.

If you take one habit from this article, make it the capital F. Most people discover the difference the hard way, at two in the morning, staring at a log that stopped saying anything at midnight and wondering why the problem went quiet. And if a server keeps producing symptoms that nobody can pin down, the answer is usually already written in a log that nobody was following properly.