tail -f: follow a log file in real time (and use tail -F for rotated logs)

Follow a file with tail -f

tail -f prints the last 10 lines of a file, then stays open and prints new lines as your job appends them, until you press Ctrl+C. Ten lines isn't much context if an error trace just scrolled past, so pass -n 100 to print the last 100 lines first, or -n +1 to print the whole file from line 1 and then follow.

You can also pass two or more files when a job splits stdout and stderr into separate logs. tail prints a ==> name <== header each time the output switches from one file to the other.

tail -f app.log
tail -n 100 -f app.log
tail -f stdout.log stderr.log

$ tail -f stdout.log stderr.log
==> stdout.log <==
out 1
out 2

==> stderr.log <==
err 1
err 2

Follow a log from your phone or another machine

tail -f only shows a log on the machine that has it, so checking a long job from your phone means an SSH app and a session that stays open. Start the job under tqdml run and Runpeek streams its stdout and stderr to a live link instead, with its tqdm bars, run time and exit code.

For a quick look from a terminal on a remote VM or cluster node, pass the tail -F command to ssh in quotes so the remote machine runs it and streams the output back. Add -t so that Ctrl+C also stops the remote tail.

ssh -t user@server 'tail -F /var/log/app.log'

tail -f vs tail -F when logs rotate

Plain -f means --follow=descriptor. That works until a rotation tool renames app.log to app.log.1 and creates a fresh app.log. tail -f keeps reading the end of the renamed file, so your terminal goes quiet even though the job is still logging.

The GNU manual says descriptor tracking isn't what you want for rotated logs and points you to --follow=name, or the shorter -F, which combines two options:

• --follow=name watches the file name, so after rotation tail opens the new app.log and tells you on stderr.
• --retry keeps trying to open a file that is missing or unreadable, which helps when you start watching before the job creates its log.

$ tail -F app.log
line 1
line 2
line 3
tail: 'app.log' has been replaced;  following new file
line 4
line 5

When tail polls instead of using inotify, it checks about once per second (-s) and reopens a file by name after --max-unchanged-stats checks without a size change, 5 by default. Expect a few seconds between the last old line and the first new one.

Here is how the common ways to follow a log compare:

Filter lines and stop automatically

To watch only failures, pipe tail -F into grep. In a terminal that prints matches right away, because GNU grep line-buffers output when it writes to an interactive device.

The trap shows up when you pipe grep into another command or a file. Then grep fully buffers and holds matches until its buffer fills: in a test, a file fed by grep ERROR was still empty after 4 seconds of matching lines. Add --line-buffered whenever grep's output isn't your terminal.

--pid=PID makes tail exit as soon as the process that writes the log dies. Pair it with $!, the PID of the last background job:

tail -F app.log | grep ERROR
tail -F app.log | grep --line-buffered ERROR >> errors.log

python -u train.py > train.log 2>&1 &
tail --pid=$! -F train.log

less +F and journalctl -f

Sometimes you spot a stack trace and want to pause the stream to scroll up and search. less +F app.log opens the file in follow mode, where the F command keeps reading at the end of the file like tail -f. Press Ctrl+C to stop following, scroll or search with /, and press F to jump back to the live end.

If your script runs as a systemd service, its output goes to the journal instead of a file. Use journalctl -f -u <unit> to follow one unit, with -n 50 to see the last 50 entries first. For containers, see how to follow Docker logs.

less +F app.log
less --follow-name +F app.log
journalctl -f -u nginx -n 50