6

I want to tail -f file but going tailing it after a mv.

The tail manpage tells me: -f means --follow=descriptor so a mv should not change the inode?

Why does tail -f stop working after the rename?

Kevin Panko
  • 7,346
  • 22
  • 44
  • 53
Psi
  • 163
  • 4

1 Answers1

3

Reading tail sources, it appears that it does not fail at reading the renamed file, but it fails at monitoring the file status.

More precisely, tail appears to behave this (simplified) way:

  1. it reads the file to the end;
  2. then setup an inotify watch in order to be noticed when something happens to the file;
  3. when new content is appended to the file, read again to the end;
  4. then jump back to step 2.

When you move the file, inotify informs tail, which in turn decides to drop the file from the list of the monitored files. It appears to be intentional, although it is not clear to me why this is so (and I would expect it to keep monitoring the file after rename). The relevant lines appear to be these.

So, the problem is not with the underlying Linux operating system, but with the way tail handles file renaming.

  • 2
    I see youre completley right. For me its a bug in `tail`, either in the code or in the documentation. I use tail wihtin a NodeJS script in wrapped it around with my own inotify watcher to re-init tail using the renamed file, not a elegant way but it works. – Psi Oct 13 '14 at 10:48
  • There used to be a utility called `tailf` (http://manpages.ubuntu.com/manpages/xenial/en/man1/tailf.1.html) that handled a file rename by opening a new file named as the command line argument, if exists. That made it useful to follow rotating log files, but it is no longer available, likely because its main feature was using inotify as explained above and when that functionality was added to `tail` - `tailf` was deemed unnecessary. – Guss Mar 17 '22 at 14:53
  • 1
    Apparently that functionality now exists as `tail -F` (https://unix.stackexchange.com/a/22699/4323). If you want to follow the original file through the rename, maybe `tail -f --retry` would work for you. – Guss Mar 17 '22 at 14:56