17

I'm tailing a log file using tail -f messages.log and this is part of the output:

Lorem ipsum dolor sit amet, consectetur adipiscing elit. 
Fusce eget tellus sit amet odio porttitor rhoncus. 
Donec consequat diam sit amet tellus viverra pellentesque. 
tail: messages.log: file truncated
Suspendisse at risus id neque pharetra finibus in facilisis ipsum.

It shows tail: messages.log: file truncated when the file gets truncated automatically and that's supposed to happen, but I just want tail to show me the output without this truncate message.

I've tried using tail -f messages.log | grep -v truncated but it shows me the message anyway.

Is there any method to suppress this message?

Improve this question

3 Answers 3

Reset to default
23

That message is output on stderr like all warning and error messages.

You can either drop all the error output:

tail -f file 2> /dev/null

Or to filter out only the error messages that contain truncate:

{ tail -f file 2>&1 >&3 3>&- | grep -v truncated >&2 3>&-;} 3>&1

That means however that you lose the exit status of tail. A few shells have a pipefail option (enabled with set -o pipefail) for that pipeline to report the exit status of tail if it fails. zsh and bash can also report the status of individual components of the pipeline in their $pipestatus/$PIPESTATUS array.

With zsh or bash, you can use:

tail -f file 2> >(grep -v truncated >&2)

But beware that the grep command is not waited for, so the error messages if any may end up being displayed after tail exits and the shell has already started running the next command in the script.

In zsh, you can address that by writing it:

{ tail -f file; } 2> >(grep -v truncated >&2)

That is discussed in the zsh documentation at info zsh 'Process Substitution':

There is an additional problem with >(PROCESS); when this is attached to an external command, the parent shell does not wait for PROCESS to finish and hence an immediately following command cannot rely on the results being complete. The problem and solution are the same as described in the section MULTIOS in note Redirection::. Hence in a simplified version of the example above:

paste <(cut -f1 FILE1) <(cut -f3 FILE2) > >(PROCESS)

(note that no MULTIOS are involved), PROCESS will be run asynchronously as far as the parent shell is concerned. The workaround is:

{ paste <(cut -f1 FILE1) <(cut -f3 FILE2) } > >(PROCESS)

The extra processes here are spawned from the parent shell which will wait for their completion.

Improve this answer
2
  • Is there a reason you're preferring a subshell ( ) over a complex command { }? Commented Sep 30, 2018 at 5:25
  • @TomHale. No good reason. See edit. Thanks. Commented Sep 30, 2018 at 7:16
11

It happened because file content

is overwritten with overwrite > - not adding with append >>.

Improve this answer
1
  • 1
    good answer... this was the root cause in my scenario Commented Dec 8, 2021 at 16:56
2

If grep doesn't get rid of the output, it's most likely being printed on standard error. The simplest way to get rid of that is to simply dump it:

tail -f messages.log 2>/dev/null
Improve this answer
2
  • 2
    Does the trick, but also suppresses other messages. Commented Nov 20, 2014 at 15:34
  • Yep, @StéphaneChazelas's got a solution which is more complex but only ignores the relevant message. Commented Nov 20, 2014 at 15:43

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.