I never used tail -F command instead always used tail -f however someone told me that -F is better without much explanation.

I looked up man page for tail command.

-f output appended data as the file grows;

-F Same as --follow=name --retry

--retry Keep trying to open a file even when it is or becomes inaccessible

It is easy to understand what lower -f does but I do not follow what upper case -F is trying to do. I'd appreciate someone can explain to me the differences.

up vote 66 down vote accepted

You describe the GNU tail utility. The difference between these two flags is that if I open a file, a log file for example, like this:

$ tail -f /var/log/messages

... and if the log rotation facility on my machine decides to rotate that log file while I'm watching messages being written to it ("rotate" means delete or move to another location etc.), the output that I see will just stop.

If I open the file with tail like this:

$ tail -F /var/log/messages

... and again, the file is rotated, the output would continue to flow in my console because tail would reopen the file as soon as it became available again, i.e. when the program(s) writing to the log started writing to the new /var/log/messages.

On the free BSD systems, there is no -F option, but tail -f will behave like tail -F does on GNU systems, with the difference that you get the message

tail: file has been replaced, reopening.

in the output when the file you're monitoring disappears and reappears.


YOU CAN TEST THIS

In one shell session, do

$ cat >myfile

That will now wait for you to type stuff. Just go ahead and type some gibberish, a few lines. It will all be saved into the file myfile.

In another shell session (maybe in another terminal, without interrupting the cat):

$ tail -f myfile

This will show the (end of the) contents of myfile in the console. If you go back to the first shell session and type something more, that output will immediately be shown by tail in the second shell session.

Now quit cat by pressing Ctrl+D, and remove the myfile file:

$ rm myfile

Then run the cat again:

$ cat >myfile

... and type something, a few lines.

With GNU tail, these lines will not show up in the second shell session (where tail -f is still running).

Repeat the exercise with tail -F and observe the difference.

  • Oh..I see. I have a system log file such as foo.log then I see sometimes foo_06242016.log along with foo.log. So I run tail -f foo.log, it will point to foo_06242016.log? – DaeYoung Jun 24 '16 at 19:31
  • 1
    @DaeYoung No, not quite. If you run tail -f foo.log and your system moves foo.log to e.g. foo.log.0.gz the output you see would just stop. If you use -F on the other hand, you would see the contents of the new foo.log without any break in-between. – Kusalananda Jun 24 '16 at 19:40
  • 4
    +1 ... thank you for not limiting your answer to GNU's implementation, but also letting people know what can be expected in another environment. – TOOGAM Jun 24 '16 at 21:03
  • 2
    Very nice illustration with the example. – a CVn Jun 25 '16 at 12:22
  • 1
    @Kusalananda: Thank you for the exercise. I observed the difference and it helped me better to understand what tail -f and tail -F do. have a blessed day! – DaeYoung Jun 27 '16 at 15:18

Simplified, when you open a file, you will get the inode that contains some metadata of where exactly the file is located on your disk. Tail will then listen for changes to that file.

If you remove the file, and create a new one with the same name the filename will be the same but it's a different inode (and probably stored on a different place on your disk). tail -f fill not retry and load the new inode, tail -F will detect this.

The same effect will happen if you rename/move a file. If you for example follows /var/log/messages and logrotate rotates the log to /var/log/messages.1. tail with -f will still listen to the old inode that points to messages.1. tail with -F will realize this and read the new inode.

  • Thanks for your explanation. It makes much sense to me now. – DaeYoung Jun 24 '16 at 19:32
  • 2
    It's okay. I understand that such a tailure can be an easy mistake to make. I'm particularly enjoying the fact that your prior spelling error has been fixed, and acknowledged... with another spelling error. :) – TOOGAM Jun 25 '16 at 9:38

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.