Stop using tail -f (mostly) (opens in new tab)

I was introduced to less +F a while ago and it is quite nice, but there is one simple "feature" of tail -f that I miss quite a lot: being able 'mark' the log with gaps by hitting enter a few times. This is especially handy when you have to first load a page or warm up the app before performing the operation you're interested in watching, letting you separate the earlier output from the lines generated by what you're testing.

With less, you have to keep track of the current position by timestamp or other unique message, and it's easy to lose your place when the output starts streaming in. With tail, you only need a moment to mark your spot and then it's visually distinct even as more message come in.

Even when you don't want less +F, a good alternative to tail -f is tail -F. It survives log rotation, and the file being temporarily inaccessible:

    --retry
	      keep trying to open a file even if it is inaccessible when  tail
	      starts  or if it becomes inaccessible later; useful when follow-
	      ing by name, i.e., with --follow=name

    -F        same as --follow=name --retry

This _almost_ touches on the useful part of this: If you search in less and then put it in follow mode, it continues to highlight the search terms. This is very useful for trapping an exception or webcall in the wild.

The downside: less buffers and tail -f prints directly. On a slow printing log this can cause events to show up slowly, and can cause performance issues on a fast moving log. If you're piping through a script for processing, tail -f is still the best bet. If you need multiple files, multitail is probably better. less +F hits a quick+easy operational niche and is available almost everywhere (whereas multitail is not).

Or use multitail. It supports syntax highlighting, among other features: http://www.vanheusden.com/multitail/

> We all have been there: You are watching a file with tail -f, and then you need to search for something in this file, or just navigate up and down. Now you need to exit tail (or open a new shell), and ack this file or open it with vim to find what you are looking for. After that, you run tail again to continue watching the file. There's no need to do that when you are using less.

There's also no need to do that if you're running tmux, screen or have navigation tools baked into your terminal emulator.

Not that I'm trying to dismiss the effectiveness for +F for those inclined, but as the author acknowledged, +F also comes with some usability issues that -f does not (namely working with multiple files, and piping output into grep et al). Plus learning to navigate though terminal history is a useful skill to have in other situations anyway, and utilities like tmux are actually a very handy tool to use for a whole plethora of additional reasons too.

So kudos to the author for his recommendation and providing helpful write ups to future sysadmins, but I'm inclined disagree with him and instead recommend people stick with -f and learn tmux instead.

If you're using a modern terminal with scrollback, you already have the ability to pause, and scroll back.

    # tail -f busy.log
    < see something of interest >
    ctrl+s # Stops flow of output.
    pgup/pgdn for navigation # fn+up/dn for OS X users
    ctrl+q # Continues flow.

No need to reinvent the wheel, the functionality you want is probably built into the tools you're already using.

Be very, very careful with this: http://seclists.org/fulldisclosure/2014/Nov/74

But really, it's 2015. Are you really using a terminal emulator without a buffer search? Are you not using screen or tmux, both of which can do these things natively, with no external tools? Why? And what is wrong with backgrounding the tail command, running your grep, and then foregrounding the tail command?

The problem is that less +F polls every second while tail -f uses inotify, which is both more efficient and responds faster to change.

It's a nice feature of less, but less is a pager, so you can't pipe the result to `grep` or `sed` or `awk` or something.

I use tail -f and when I need to search, I use iTerm's search (Cmd+F) which highlights matches and even supports regex. I also have an unlimited scroll buffer so I can just scroll up or down to get the context of a particular match.

I use tail -f with tmux usually. Will less +F save the entire output into memory? In other words, if I accidentally leave it open in a tmux shell and the log grows to 300mb of output, will the server start swapping?

For lazy people out there:

There is also the command `tailf` which is quite similar to 'tail -f'.

2 characters make so much difference :)

For semi-large file (1/2GB+) less takes seconds if not minutes to count the number of lines (it read the whole file) so you can navigate and search across the file. In that cases tail -f and grep are still way faster than less, though less is a handier tool

Or just tail -f in an emacs buffer

less +F is not such a good alternative to "tail -f" or better "tail -F" especially when you are filtering the output of tail using grep or awk.

Linux just really needs PowerShell.

If you're looking at log files, a tool I've started to play with is http://lnav.org/

= In Your Terminal = Many logging tools, like Splunk, provide great features but are optimized for large-scale deployments. They require installing and configuring servers before they can be effectively used. There is still a need for a robust log file analyzer for the terminal.

= Easy to Use = Just point lnav to a directory and it will take care of the rest. File formats are automatically detected and compressed files are unpacked on the fly.

= Improved Presentation = Log files are a wealth of information, lnav can help highlight the parts that are important and filter out the noise.

On current Linux distros, you're more likely to use:

    journalctl -u service-name -f

-f, --follow Show only the most recent journal entries, and continuously print new entries as they are appended to the journal.

Interesting.

I always preferred

  watch -n 1 -d 'tail /path/to/log/file'

to tail -f

because of its nice highlighting feature.

+1 for Commandline Fu. I love it when you see a colleague at a terminal and you say "Whoah, go back, what was that you just did?". It's kinda beautiful really, the way everyone has slightly different methods for common dev tasks at the commandline.

My method is usually '+G' to go to the end of the log file and check the damage report. Quick reverse search with '?' + search term to find last error, then probably hit 'n' to find the next previous any other occurrences to determine how frequent it's popping up. If it looks like it's a recurring problem i'll '+F' to see follow latest output. Then CTRL+c to quit that mode.

tail -f still has it's uses for cases as pimlottc mentioned. I like to put a bit of distance between the last bit of output. Especially if its a particularly repetitive and lengthy stacktrace.

less is my favorite text editor. It's a pity it doesn't actually edit text.

The biggest nag I have with tail is that it stops tracking a file once it gets moved and a new one is created in its place (through log rotation).

It would be awesome to remove the "Waiting for data... (interrupt to abort)" message.

Doesn't read ANSI color codes! Looking through manual for that.

Wait... Isn't less gonna read the whole file at first? That might suck for files that are already huge.

tail works best for me. I'm not going stop using it just because a person on the internet says not to.

Not convinced, still like tail -f because you can hit enter a couple of times and there you are... a nice visual mark to wait for new data without getting confused by existing content.

All this in my humble opinion. less is useful and I may use F to wait for data if I was looking for something in old logs, but for new data I still like tail -f :)

I use tail -f inside tmux anyways, so I already have the extra feature less offers ("navigation mode", searching, etc) without giving up the "watch multiple files" feature.

A much nicer alternative, IMHO.

There's also lnav (http://lnav.org), the Logfile Navigator. It can do what 'tail -f' and 'less' do plus: syntax coloring, filtering, loading compressed files, interleaves log messages from multiple files, and more.

Many of the comments I see on here about using '-F' with tail instead of '-f', live searching, and so on are handled in lnav by default. I would really encourage folks to give it a try.

One advantage that tail -f has is that you can insert newlines or other characters into the output to help you visually split log entries. Log files often look the same so being able to visually split up the log is very helpful IMO.

Huge caveat: "less +F" does not work with multiple files.

Yes, this is mentioned in the post, but I feel it is so big it would have deserved large, bold letters.

I use tail -f mainly for tracking something end-to-end through multiple log files because it's pipeable to grep or awk, where less is not. less +F is cool too, but tail -f is more useful when doing complex log analysis on the fly because it follows standard UNIX I/O behavior.

I just tried this on an extremely active logfile and it didn't work very well for me. I'd recommend multitail for watching constantly changing files.

Stop using [commonly accepted, proven method] and use [obscure alternative]

Textbook HN hit.

What do people (you) think about browser based log viewers like e.g. logio.org? I like to comfortably have all the logs in the browser but do not want to go full ELK (or anything in this category) stack just for a few servers. But I am not sure if there is some better solution? Multitail is great, but sometimes just opening a new browsertab is even greater...

Searching with less is a cool feature, but I think the best thing I learned was to use -F instead of -f with tail thanks to the comments on the article and HN.

Of course I'll probably fail to use any of it because of finger memory just typing out tail -f for me.

I would be careful about such casual use of less: http://seclists.org/fulldisclosure/2014/Nov/74

It's amusing to read this just as, for the first time in months, I have a "tail -f" running. I just converted a medium-sized system from Python 2 to Python 3 (this is not fun; I had to fix or work around five bugs in external modules), and deployed it this morning. So I have a "tail -f" running in "putty", watching an Apache server error log. (I know, retro.) This is just in case there's some new Python-level error; operational errors are logged to the database. The log is quiet, and soon I can stop watching.

I was interested in the significance of the plus for this flag. If anyone else was curious: from the manual, the + flag is for initial commands to less, so this is equivalent to running less and typing F.

Thanks! This is really great trick. I will obviously use less +F for tailing single file.

Meanwhile, tail -f still useful for simple tailing to multiple machine, like

    function dogfight_tail {
     logfile=/var/log/nginx/access.log
     pids=""
     for box in 02 03; do
       ssh lb$box tail -f $logfile | grep " 500 " & # find error machines
       pids="$pids $!"
     done
     trap 'kill -9 $pids' SIGINT
     trap  wait
    }

    dogfight_tail

I use "tail -f" most of the time. Sometimes, I just dig more and use grep with it.

tail -f sys.log | grep NETDEV

But I would definitely give this a try, thanks for sharing.

I think that it's worth noting that you should still use `-f` if you are viewing a file over SSH that is being appended to a ton and you don't need every line. SSH will require that every line makes it to your terminal over it's secure connection, so you will be bottlenecked and most likely won't be viewing the latest messages. Everything will be queued.

I think I'll do the following (as a joke, surprised no one did it already):

  $ alias stalk='less +F'

I just had an SRE screening and one of the questions was

"What is a linux command that's mostly not known?".

I could not remember anything that's special, at least for me at the time but "less -F" poped up to my mind. Thank you :)

Oh now I can think of ccze, column and tac. Interviews..

With `tmux` there is a visual mode that allows to `tail -F` with search, selection etc.

For something simple and very lightweight for Windows development, check out BareTail: http://www.baremetalsoft.com/baretail/

Haha I didn't know a lot of people didn't know about this. I am one of those people who likes to read man pages :D Another favorite one of mine is the `v` switch to quickly jump to the editor from `less`. Pretty handy!

While I understand that the author is just trying to be helpful, the provocative title of the article makes me want to scream: "Stop telling me which tool is right for MY job."

I've literally never had this problem and nothing is wrong with tail -f for me. Quitting tail to use grep on the file is anything but inconvenient for me.

This is pretty awesome. I have always thought that "tail -f" was a little limited but still useful. Any how, great post!

For log files that move particularly fast, I prefer to use "watch tail -n 100" so I don't choke my connection.

Good share! Command line fu is always nice.

$make -j16 showcommands > build.log 2>&1 | less +F

ctrl+c...

<shit its not working>

ctrl+c * 1e9 impatiently

...

build stopped

oops

"here you have pretty much the same behavior"

what is meant by 'pretty much?'

Perhaps neovim with terminal mode and tail -F might be the best of all worlds.

Imma just gonna leave this here: http://seclists.org/fulldisclosure/2014/Nov/74

Why not just pipe the output of tail -f through less?

Put that kind of suggestion in coderwall.com

Solaris 10 doesn't have the -F flag.

Can I hack someone's pay face book

U dont tell me what to do! i like my tail

/thefox

Can you hack face book account

its not better for me, hitting enter is essential for me when using tail

...or use multi-tail

wow... this is really a nice coomand

Nice!