8

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?

12

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.

  • Is there a reason you're preferring a subshell ( ) over a complex command { }? – Tom Hale Sep 30 '18 at 5:25
  • @TomHale. No good reason. See edit. Thanks. – Stéphane Chazelas Sep 30 '18 at 7:16
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
  • 1
    Does the trick, but also suppresses other messages. – Bas Peeters Nov 20 '14 at 15:34
  • Yep, @StéphaneChazelas's got a solution which is more complex but only ignores the relevant message. – l0b0 Nov 20 '14 at 15:43
0

Maybe help if can be fixes origin of this error. It happened because something write to file with overwrite ">" not with append ">>".

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.