GNU tail File Following (Unix Power Tools, 3rd Edition)

12.11. GNU tail File Following

I like to keep an xterm window open on my Linux system so I can watch various log files. Although there are fancier log-file-monitoring programs (such as swatch), tail -f (Section 12.10) is perfect for me.

I also run a weekly cron (Section 25.2) job to rotate log files (rename the files, compress and archive them). When this job runs, the log files suddenly have new names -- messages becomes messages.1, for instance -- so the system logger starts writing to a different messages file. Then plain tail -f suddenly stops showing the log because it doesn't realize that the same physical file on the disk suddenly has a new name. When this happened, I had to remember to kill and restart tail each Sunday morning . . . until I found the new version of GNU tail, that is.

The GNU tail - -follow option lets you choose how the files you're watching should be followed. By default, GNU tail acts like the standard tail: it opens a file for reading and gets a file descriptor (Section 36.15) number, which it constantly watches for changes. But if that file is renamed and a new file with the old name (and a new inode) takes its place, the file descriptor may point to a file that's not in use anymore.

Go to http://examples.oreilly.com/upt3 for more information on: tail

The GNU tail options, - -follow=name and - -retry, tell it to watch the actual file name, not the open file descriptor. Here's what happens Sunday mornings when I'm using this:

{ } Section 28.4

kludge# tail --follow=name --retry ~jerry/tmp/startx.log \
  /var/log/{messages,maillog,secure}
   ...lots of log messages...
tail: `/var/log/secure' has been replaced;  following end of new file
tail: `/var/log/maillog' has been replaced;  following end of new file
tail: `/var/log/messages' has been replaced;  following end of new file
Dec 31 04:02:01 kludge syslogd 1.3-3: restart.
Dec 31 04:02:01 kludge syslogd 1.3-3: restart.
Dec 31 04:02:05 kludge anacron[8397]: Updated timestamp for job
`cron.weekly' to 2000-12-31

It's just what I've always needed.

-- JP