● UK tech experts · info@vividrepairs.co.uk
Vivid Repairs
Linux terminal on a dark developer workstation showing tail -f command monitoring a live log file with scrolling output
Fix It Yourself · Troubleshooting

tail follow file changes

Published 27 August 202611 min read
As an Amazon Associate, we may earn from qualifying purchases. Our ranking is independent.

Spent 20 minutes on a remote session last month with a developer who was convinced their logging service had stopped writing entirely. It hadn't. They were just running plain tail and wondering why nothing new appeared. If tail follow file changes isn't working for you, the fix is almost always one flag away. But there are a few nastier causes worth knowing about too.

TL;DR

Plain tail and cat print file contents once and exit. To make tail follow file changes, use tail -f for basic follow mode or tail -F for log files that get rotated. If you still see nothing, check permissions with ls -l and confirm the file is actually being updated with stat.

⏱️ 13 min read ✅ 90% success rate 📅 Updated August 2026

Key Takeaways

  • tail follow file changes requires the -f or -F flag. Plain tail exits immediately after printing.
  • tail -f follows the inode. If the file is rotated or recreated, it loses track. Use tail -F instead for log files.
  • If tail -f shows nothing at all, check permissions first, then confirm the file is actually changing with stat.
  • Writer-side buffering can make updates invisible even when the process is running fine. The fix is on the application side, not the tail side.
  • cat has no follow mode. It will never show new content. Use tail -f or tail -F.

At a Glance

  • Difficulty: Easy
  • Time Required: 15 mins
  • Success Rate: 90% of users

What Causes Tail Follow File Changes to Stop Working?

The most common reason is the simplest one: people run tail /var/log/app.log or cat /var/log/app.log and expect it to keep updating. It won't. Both commands read the file once and exit. That's it. There's no magic background process keeping the output alive. To get tail follow file changes behaviour, you have to tell tail explicitly to stay open with -f or -F.

But say you're already using tail -f and still seeing nothing new. That's where it gets more interesting. Here are the actual causes in rough order of how often I see them:

  • No follow flag at all. Plain tail or cat used instead of tail -f. Accounts for probably 60% of these calls.
  • File rotation. The writing process rotates its log file, creating a new file at the same path. tail -f follows the original inode, so it keeps watching the old renamed file and never sees the new one. The terminal goes quiet.
  • Writer-side buffering. The application writing to the file is buffering output in memory and only flushing to disk in large chunks or at intervals. The file size doesn't change for minutes at a time even though the process is running fine.
  • Permission issues. You don't have read access to the file or its parent directory. tail -f might open without error but show nothing, or throw a permission denied message.
  • Wrong file path. The process is writing to a different location than you think. Symlinks, relative paths, and environment-specific log directories catch people out regularly.
  • File truncation or in-place rewriting. Some applications don't append. They rewrite the whole file from scratch each time. tail -f only shows content added to the end, so a truncate-and-rewrite cycle can look like nothing is happening.

The Linux man page for tail covers the technical distinction between inode-following and name-following in detail if you want the full picture. For most people, the practical takeaway is: -f for simple cases, -F for anything involving log rotation.

One thing worth flagging: if you're trying to read systemd journal logs with tail -f on a file under /run/log/journal/, you're going to have a bad time. Those are binary files. Use journalctl -f instead. tail is designed for plain text streams appended line by line, and that's where it works well.

Tail Follow File Changes: Quick Fix

Nine times out of ten, this is all you need.

1

Enable Follow Mode with tail -f Easy

  1. Stop whatever you're currently running.
    Press Ctrl+C to exit plain tail or cat.
  2. Run tail with the -f flag.
    tail -f /path/to/file
    This keeps the command open and prints each new line as it's written to the file. You'll see the cursor sit there waiting. That's correct behaviour.
  3. Verify it's working.
    Trigger some activity in the writing process (make a request, generate an event, whatever applies). New lines should appear in your terminal within a second or two. If they do, you're sorted.
New lines scrolling in the terminal confirms tail follow file changes is working correctly.
If the file is a log that gets rotated (common with nginx, Apache, or any app using logrotate), skip straight to Solution 2. Using -f alone will break silently after rotation.

More Tail Follow File Changes Solutions

2

Use tail -F for Rotated Log Files Easy

  1. Understand the difference first.
    tail -f follows the inode of the file it opens. When logrotate renames app.log to app.log.1 and creates a fresh app.log, tail -f keeps watching the renamed file. You see nothing new. tail -F follows the filename instead, so it notices when the path points to a new file and switches automatically.
  2. Run tail with the -F flag.
    tail -F /path/to/file
    You'll see a message like tail: '/path/to/file' has been replaced; following new file when rotation happens. That's the flag doing its job.
  3. Verify across a rotation event.
    If you can trigger a log rotation manually (e.g. sudo logrotate -f /etc/logrotate.conf), do it while tail -F is running. It should print the replacement notice and continue showing new output from the fresh file without you having to restart anything.
tail -F is the correct default for any production log file. Use it instead of -f and you won't lose output after rotation.
3

Check File Permissions Easy

  1. Check who owns the file and what permissions are set.
    ls -l /path/to/file
    Look at the owner, group, and permission bits. A file owned by root with mode 640 won't be readable by a regular user.
  2. Try with sudo to confirm the cause.
    sudo tail -f /path/to/file
    If this works and plain tail -f doesn't, the problem is definitely permissions, not the command itself.
  3. Fix access properly.
    Rather than always running as root, add your user to the relevant group. For example, many distros put log files in the adm group: sudo usermod -aG adm yourusername. Log out and back in for the group change to take effect.
You should be able to run tail -f without sudo after the group change takes effect.
4

Confirm the File Is Actually Being Updated Easy

  1. Check file metadata with stat.
    stat /path/to/file
    Note the file size and the Modify timestamp. Wait 15 to 30 seconds and run it again.
  2. Compare the two outputs.
    If the size and modification time haven't changed, the writing process is either not running, writing to a different path, or buffering output and not flushing to disk.
  3. Check the inode number.
    ls -li /path/to/file
    The first column is the inode. If the inode changes between checks, the file is being replaced rather than appended to. This is why tail -f loses track. Switch to tail -F.
  4. Find where the process is actually writing.
    If you control the writing process, check its configuration for the log path. Or use lsof -p <PID> to see every file the process has open. The actual log file will show up there.
Once you confirm the file size is changing and you're watching the right path, tail follow file changes should work with -f or -F.

Advanced Tail Follow File Changes Fixes

If the quick and intermediate fixes haven't sorted it, one of these less obvious causes is probably the culprit.

5

Deal with Writer-Side Buffering Medium

  1. Identify whether buffering is the cause.
    If stat shows the file size is growing, but only in large jumps every few minutes rather than line by line, the writing process is buffering. The file is being updated, just not as frequently as you'd expect.
  2. Check the polling interval on tail.
    tail -f -s 1 /path/to/file
    The -s flag sets the sleep interval between checks in seconds. Default is usually around 1 second already, but making it explicit can help on some systems. This won't fix buffering but it rules out tail itself being the delay.
  3. Fix the writer if you control it.
    If it's a Python script, run it with python -u script.py for unbuffered output, or call sys.stdout.flush() after each write. For C programs, use fflush(stdout) or set setbuf(stdout, NULL). For shell scripts, echo is typically line-buffered already, but redirecting through a pipe can introduce buffering. Use stdbuf -oL to force line buffering: stdbuf -oL your_command >> /path/to/file.
  4. If you don't control the writer, accept the delay.
    Some applications only flush logs on a schedule or when the buffer fills. In that case, tail -f will show updates, just not in real time. There's nothing you can do on the monitoring side to change that.
After fixing buffering on the writer side, tail -f should show new lines appearing promptly rather than in delayed bursts.
6

Handle In-Place Rewriting and Truncation Medium

  1. Detect truncation.
    Run stat /path/to/file repeatedly. If the file size drops back to zero or a small value periodically, the process is truncating and rewriting rather than appending. tail -f only shows content added to the end of the file. A truncate event resets the position and you may see nothing or see the same content repeated.
  2. Check whether tail -F handles it.
    Some truncation patterns are treated as file replacement events. Try tail -F /path/to/file and watch whether it picks up content after the truncation. On GNU coreutils, tail -f does actually detect truncation and resets its position, so you should see new content appear after the truncation. But behaviour varies by system.
  3. Consider a different monitoring approach.
    If the file is being rewritten entirely rather than appended to, tail isn't the right tool. You might be better off using watch cat /path/to/file to see the full current state on a refresh interval, or writing a small script that diffs the file contents between reads. The GNU coreutils documentation for tail explains exactly how truncation detection works under the hood if you want to get into the specifics.
Once you understand whether the file is being appended to or rewritten, you can pick the right monitoring tool for the job.
Monitoring multiple files at once? tail -f handles it fine: tail -f /var/log/app.log /var/log/error.log. Each new line is prefixed with the filename so you know which file it came from. Add -q to suppress those headers if you'd rather not see them. For a broader look at Linux log management, HowToGeek's tail command guide covers the common use cases well.

Preventing Tail Follow File Changes Problems

Most of these problems are avoidable with a couple of habits. Here's what actually matters, in order of importance:

1. Default to tail -F, not tail -f. For any production log file, tail -F is the safer choice. It handles rotation automatically and doesn't go silent after a logrotate run. There's no real downside to using it over -f for normal files. Make it your default and you'll avoid the most common version of this problem entirely.

2. Get permissions right from the start. If your monitoring user can't read the log directory, you'll get nothing and it won't always be obvious why. Set up group membership properly (usually the adm group on Debian-based systems) rather than relying on sudo for routine log watching. Running everything as root because it's easier is a bad habit that creates bigger problems later.

3. Know your log format before picking your tool. Plain text files appended line by line: use tail -F. systemd journal: use journalctl -f. Binary or structured formats: use whatever the application provides. Forcing tail onto a binary log file produces garbage output and wastes time. If you're working with Linux permission structures more broadly, our Linux file permissions guide covers the common gotchas in detail.

4. Configure your applications to flush promptly. If you control the writing process, line-buffered output is almost always the right setting for log files. Delayed flushing makes debugging harder and gives you a false impression that nothing is happening. It's a small configuration change that saves a lot of confusion.

5. Standardise your log paths. Log files scattered across custom directories with non-standard names are a maintenance headache. If you're setting up a new service, put logs somewhere predictable, document the path, and set up rotation with logrotate from day one. Future you will be grateful. For teams managing multiple Linux servers, our Linux server monitoring setup guide covers building a consistent logging workflow.

Tail Follow File Changes: Summary

The core of tail follow file changes is simple: plain tail and cat don't follow anything. They read and exit. Add -f to keep tail running and watching for new content. Switch to -F if the file might be rotated or recreated, which covers most real-world log files. If follow mode still shows nothing, check permissions with ls -l, confirm the file is actually changing with stat, and check the inode with ls -li to see if the file is being replaced rather than appended to. Writer-side buffering is the trickiest cause because everything looks fine from the outside, but the fix is on the application side, not the tail command. Sort those five things and tail follow file changes will work exactly as expected.

Frequently Asked Questions

Plain tail prints the last 10 lines of a file once and then exits. It does not monitor the file for changes. Use tail -f to follow newly appended lines continuously.

tail -f follows the inode of the original file, so it stops showing updates if the file is rotated or recreated. tail -F follows the filename instead, automatically switching to the new file if the original is replaced. For log files, tail -F is almost always the better choice.

When a log file is rotated, the original file is renamed or deleted and a new file is created at the same path. tail -f keeps watching the old inode and never sees the new file. Switch to tail -F to fix this permanently.

No. cat prints the entire file contents once and exits. It has no follow mode. Use tail -f or tail -F for continuous monitoring of new appended lines.

The most common causes are: wrong file path, missing read permissions, the writing process is buffering output and not flushing to disk, or the process is rewriting the file in place rather than appending. Check the path with stat, check permissions with ls -l, and verify the file size is actually changing.