Why does `read -t` not sync in bash on RHEL?

Question

Why does read -t not disconnect when reading from a pipe on RHEL5 or RHEL6?

Here is my example that does not include a timeout in my RHEL boxes reading the channel:

 tail -f logfile.log | grep 'something' | read -t 3 variable 

If I'm right, read -t 3 should expire after 3 seconds?

Thank you very much in advance.

Chris

 GNU bash, version 4.1.2(1)-release (x86_64-redhat-linux-gnu) 

Answer 1

Without answering your specific question, you need to run something like

 read -t 3 variable < <( tail -f logfile.log | grep "something" ) 

so that the new variable setpoint is visible after the completion of the pipeline. See if this deadline expires.

---

Since you just use read as a way to exit the pipeline after a certain time, you don’t have to worry about the variable scope. However, grep can find a match without printing it for a timeout due to its own internal buffering. You can disable this (with GNU grep , at least) using the --line-buffered option:

 tail -f logfile.log | grep --line-buffered "something" | read -t 3 

Another option, if available, is the timeout command as a replacement for read :

 timeout 3 tail -f logfile.log | grep -q --line-buffered "something" 

Here we kill tail after 3 seconds and usually use the grep exit status.

Answer 2

The solution given by chepner should work.

An explanation of why your version is not simple: when you build a channel like yours, the data goes through the pipe from left to right. However, if your read does not work, the programs on the left side will continue to work until they notice that the pipe is broken, and this only happens when they try to write to the pipe.

A simple example:

 cat | sleep 5 

After five seconds, the pipe will be broken because sleep will exit, but cat will continue to work until you press return.

In your case, this means that until grep gives the result, your team will continue to work, despite the timeout.

Answer 3

I don't have an RHEL server to test your script right now, but I could bet that reading is timed out and works as it should. Try to run:

 grep 'something' | strace bash -c "read -t 3 variable" 

and you can confirm it.