I'm viewing a log file with "tail -f" using GNOME Terminal. The log has a lot of input constantly coming into it, and what I find happens is that I scroll up to a previous section, and I'm reading it, and then the screen goes black, or gets replaced with text which is further down the file.

I don't know if this is the problem, but it's as if tail can only hold so many lines in memory, and when a certain number come in after the ones I'm reading, it deletes the ones I'm reading.

The number of subsequent lines which need to come in to make this happen isn't too huge - about 600 (~55,000 bytes) lines in an experiment I just did. I'd like to increase this to about 20,000 lines (or 1,000,000 bytes, say, if it's counted in bytes). Can anyone tell me how to do this? thanks

PS - someone reading this might be tempted to say "this isn't what tail -f is for, it's just for reading the end of files". I like to have the best of both worlds - to press "Enter" to get to the end of the file and see what's happening now, but also to be able to scroll up and see what happened previously.

  • This is your terminal (emulator), not tail. tail -f just writes to standard output. The terminal probably has a "scrollback size" setting, but you'll need to say what it is for someone to be able to tell you where to find it. – Michael Homer Apr 13 '15 at 9:23
  • 1
    It's a known bug in gnome-terminal that when the text you're viewing scrolls off from the scrollback buffer, the display goes blank upon refreshing. See bugzilla.gnome.org/show_bug.cgi?id=160127. The code is written in a safe way so that even though the display is temporarily garbled, the code won't go haywire. – egmont Apr 25 '15 at 16:44

GNOME-Terminal's scrollback setting is under Edit->Preferences->Profiles->Edit->Scrolling. The default value appears to be 8,192 lines on my install, but you can set it to what you want or disable the limit entirely.

You can also use a pager such as less for the same purpose:

tail -f file | less

Note that storing unlimited history in memory may end up taking a fairly large chunk of memory in long-running tasks. Using a pager will allow much of the buffer to be cleared when you exit the pager, while in the terminal it lasts as long as your terminal session.

You may find this past answer about scrollback buffers helpful to understanding what's going on.

| improve this answer | |
  • This was the issue - thanks! It was set to 512 lines. I agree that setting it to unlimited is not a good idea - i've set it to 20,000 lines, which shouldn't use more than a couple of meg of memory i think. – Max Williams Apr 13 '15 at 9:49
  • Gnome-terminal stores the scrollback buffer on disk rather than in memory. This has the benefits that you're less likely to run out of disk than of memory, and even if it happens, it's less harmful to the whole system. An obvious drawback (data leakage) was fixed in gnome-terminal-3.16 (actually the underlying vte-0.40), the data is now encrypted (and compressed as well, so save even more space). – egmont Apr 25 '15 at 16:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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