Tail Command – Fix `tail -f` Stopping Updates

loggingrhel5tail

I have noticed recently that sometimes tail -f <logfile> will stop updating to the screen.

Doing a Ctrl>–C and restarting the tail works fine, though. And I checked to make sure the logfile isn't being rotated midstream (which can make tail lose its mind).

What would cause this? I'm running RHEL 5.2 x64.

Best Answer

Try wrapping your tail command with strace if you have it:

strace -Tt -o /tmp/tail.trace tail -f /var/log/messages

Then just for crazy recursive kicks you can tail the strace output (doesnt' matter if that breaks because its going out to a file):

 tail -f /tmp/tail.trace

Mine looks like:

8:39:00 write(1, "ng SMAC\n", 8)       = 8 <0.000026>
18:39:00 read(3, "", 0)                 = 0 <0.000019>
18:39:00 fstat64(3, {st_mode=S_IFREG|0640, st_size=92990, ...}) = 0 <0.000019>
18:39:00 fstatfs64(3, 84, {f_type="EXT2_SUPER_MAGIC", f_bsize=4096, f_blocks=4807069, f_bfree=1924458, f_bavail=1680271, f_files=1221600, f_ffree=820806, f_fsid={-1331083162, -1313908385}, f_namelen=255, f_frsize=4096}) = 0 <0.000021>
18:39:00 inotify_init()                 = 4 <0.000033>
18:39:00 inotify_add_watch(4, "/var/log/messages", IN_MODIFY|IN_ATTRIB|IN_DELETE_SELF|IN_MOVE_SELF) = 1 <0.000041>
18:39:00 fstat64(3, {st_mode=S_IFREG|0640, st_size=92990, ...}) = 0 <0.000019>
18:39:00 read(4,

The -t switches on the time and -T switches on time spent in calls.

Hit return 4 or 5 times to make a bit of vertical space, then wait for it to stop tailing. Hopefully there will be some clues in the output.

Related Solutions

Linux – tail -f without the tail

tail -9999f will do something close to what you want. Add more 9s if your file is bigger.

Problems:

Binary files may not have newline characters. tail -f will wait for a newline before printing anything out.
The version of tail on Solaris (you didn't mention which Solaris but it probably doesn't matter) probably doesn't support that option. It may support tail -n 9999 -f. You may have to acquire the GNU version of tail.
Because the file is constantly growing, there is a race condition between finding out how big it is and starting the tail process. You could miss the start of the file if you don't ask it to get enough lines.
tail won't know when you have really finished writing to the file so your gzip process will never finish either. I'm not sure what will happen when you ctrl-c to end the tail process but it's likely that gzip will clean up after itself and remove the file it was working on.

My suggestion would be to start your original program up and pipe the output to gzip like this:

./my_program | gunzip > new_file.txt

That way, gunzip will wait if my_program is going slow but will still finish when the true end of the file is indicated by my_program finishing.

You may need to rewrite your program to write to STDOUT rather than directly to a file.

Edit:

After a look at the man page, three of the issues above can be resolved. Using the -c <bytes> option instead of -n <lines> mitigates problem 1. Using -n +0 or -c +0 mitigates problem 3. Using --pid=<PID> will make tail terminate when the original program ( running as <PID> ) terminates which mitigates problem 4.

Centos – tail -f : `tail: logfile.log: file truncated`

I dont know if its just a typo.. but shouldnt it be ..../script.rb >> /home/web/logfile.log for it to propertly append? Your code seems to have a space between the double angle bracket

I tried it just now on bash in mac, it prompted an error, perhaps some shells may just ignore the second angle arrow in this case

Best Answer

Related Solutions

Linux – tail -f without the tail

Centos – tail -f : `tail: logfile.log: file truncated`

Related Topic