Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

My question is as simple as what the zenity --text args say in the example... but what is causing this 100% CPU grab by the redirection?
...(and by the way, is this particular usage of < actually called redirection. It seems like it is creating a direction, rather than re-directing )..

echo "Peacocks talking of the colour grey."> test
cat test | zenity --text='This does NOT hog the CPU'   --list --column='#' --width=450 
<test      zenity --text='This hogs 100% of CPU usage' --list --column='#' --width=450

I'm quite happy to use cat test | (because it isn't useless in this case; it works and < and | are somehow different, but I haven't been able to track it down again...

To be clear: <test and cat test | both work. The zenity dialog appears and is fully functional in both cases, but for as long as the <test version of the dialog is kept open, it uses 100% CPU (of one core)... 94% on the single "core" VMs...

share|improve this question
As long as test file exists, I do not see any difference. – enzotib Jul 16 '11 at 3:38
I've tried in Ubuntu 10.04, 10.10 and 11.04.. The same thing happens in all of them... (10.10, and 11.04, are recently installed and updated VirtualBox guest VMs. The host is 10.04 – Peter.O Jul 16 '11 at 4:13
up vote 5 down vote accepted

It looks like a bug in zenity. You can see what is going on by using the strace tool (I've wrapped the strace lines in this post to make it easier to read).

With the pipe version, this line in strace shows what happens when the pipe is closed (because cat exits):

poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=0, events=POLLIN}], \
     3, 0) = 1 ([{fd=0, revents=POLLIN|POLLHUP}])

That part at the end - fd=0, revents=POLLIN|POLLHUP, in particular POLLHUP - tells zenity that stdin has hung up (writer of the pipe has gone away). Zenity is processing this correctly and closing fd 0 later.

Files do not get POLLHUP events - instead a read(2) result of zero means EOF. This is a different code path for zenity. It polls again for fd 0 and this is what it gets:

poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=0, events=POLLIN}],\
     3, 0) = 1 ([{fd=0, revents=POLLIN}])
read(0, "", 1024)       = 0

That should be the end of it - the zero read should cause zenity to close fd 0. But it doesn't. The strace output above keeps repeating, as zenity keeps polling fd 0. Until fd 0 is closed, it will always be ready for reading, as that is how file descriptors at EOF work, since you need to read it to get the EOF result.

Because zenity is not responding correctly to EOF on stdin, it keeps looping on a poll(2)/read(2) loop, where poll returns immediately, as does read. Again, and again and again...

share|improve this answer
@camh: Wow!... That is some awsome super-sleuthing... I initially couldn't quite understand your explanation, but then something gelled when I read Caleb's comment of, "sending the data as a stdin pipe vs passing a file descriptor"... Your explanation became crystal clear!... (so, in summary, I this means: don't use <file with zeinty, but piping data to it is fine)... Thanks, from a happy camper :)... – Peter.O Jul 16 '11 at 18:38

Try this:

zenity --text='This does NOT hog the CPU' --list --column='#' --width=450 <(cat test)
share|improve this answer
It doesn't hog the CPU, but it also doesn't display the contents of of 'test'. It displays /dev/fd/63 instead... but sed -n p <(cat test) works fine.. it outputs the correct text... Maybe it is just a zenity thing, but I'd still like to know what the diffeence is between '<test' and 'cat test |' that zenity is having problems with. – Peter.O Jul 16 '11 at 4:54
This answer should have no effect on the bug, zenity would see this the same as <test. The difference is in sending the data as a stdin pipe vs passing a file descriptor to be opened and read by the program. – Caleb Jul 16 '11 at 15:02

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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