grep hanging on a pipe

[unruh]

I was using grep -r "name$a.b" /var/spool/postfix
to see if there were any files being spooled to that user. But the
command never completed, and seemed to be hung on the pipe public/pickup
(Ie the prompt never reappeared). ^C got me out of this but why is it hanging?
Should not grep be wary of pipes?

[Aragorn]

On Thursday 20 October 2011 23:01, unruh conveyed the following to
alt.os.linux...

Not having an idea on why it failed either, I would suggest strace'ing
it. That should at least tell you what exactly it's hanging on.

--
= Aragorn =
(registered GNU/Linux user #223157)

[unruh]

Ask and ye shall receive.

....
stat64("./public/flush", {st_mode=S_IFSOCK|0666, st_size=0, ...}) = 0
open("./public/flush", O_RDONLY|O_LARGEFILE) = -1 ENXIO (No such device
or address)
write(2, "grep: ", 6grep: ) = 6
write(2, "./public/flush", 14./public/flush) = 14
write(2, ": No such device or address", 27: No such device or address) =
27
write(2, "\n", 1
) = 1
stat64("./public/qmgr", {st_mode=S_IFIFO|0622, st_size=0, ...}) = 0
open("./public/qmgr", O_RDONLY|O_LARGEFILE) = 3
read(3, <unfinished ...>


It is trying to read from the pipe public/qmgr. after 5 sec, I ^C to get
out.

[Richard Kettlewell]

unruh <un...@physics.ubc.ca> writes:

> I was using grep -r "name$a.b" /var/spool/postfix
> to see if there were any files being spooled to that user. But the
> command never completed, and seemed to be hung on the pipe public/pickup
> (Ie the prompt never reappeared). ^C got me out of this but why is it hanging?

Try adding --devices=skip to the command line.

--
http://www.greenend.org.uk/rjk/

[Aragorn]

On Friday 21 October 2011 07:45, unruh conveyed the following to

Well, I was hoping for something more indicative, but it appears to be
hanging on the pipe itself, as you said. So it's working correctly up
to that point.

Could it be a permissions problem, perhaps? Or could the file be
corrupted somehow, or simply very large?

[Richard Kettlewell]

Aragorn <str...@telenet.be.invalid> writes:
> On Friday 21 October 2011 07:45, unruh conveyed the following to
> alt.os.linux...

>> It is trying to read from the pipe public/qmgr. after 5 sec, I ^C to
>> get out.
>
> Well, I was hoping for something more indicative, but it appears to be
> hanging on the pipe itself, as you said. So it's working correctly up
> to that point.
>
> Could it be a permissions problem, perhaps? Or could the file be
> corrupted somehow, or simply very large?

It's perfectly obvious what's going on even without strace. It's
reading from a pipe, nothing is writing to the pipe, therefore it waits.
The answer is to not read from the pipe in the first place.

--
http://www.greenend.org.uk/rjk/

[unruh]

Yes, that works. Thanks
Now lets see if I remember it. It would seem good to have that as the
default on a grep -r instead of the present default which is "read".

[unruh]

It seems it never gets any end of file from the read of the pipe so
keeps trying to read more. The suggestion to use the -D option works,
but it really should be the default.

[Lew Pitcher]

On October 21, 2011 11:43, in alt.os.linux, un...@physics.ubc.ca wrote:

> On 2011-10-21, Aragorn <str...@telenet.be.invalid> wrote:
>> On Friday 21 October 2011 07:45, unruh conveyed the following to
>> alt.os.linux...
>>
>>> On 2011-10-21, Aragorn <str...@telenet.be.invalid> wrote:
>>>> On Thursday 20 October 2011 23:01, unruh conveyed the following to
>>>> alt.os.linux...
>>>>
>>>>> I was using grep -r "name$a.b" /var/spool/postfix
>>>>> to see if there were any files being spooled to that user. But the
>>>>> command never completed, and seemed to be hung on the pipe
>>>>> public/pickup (Ie the prompt never reappeared). ^C got me out of
>>>>> this but why is it hanging? Should not grep be wary of pipes?

[snip]

> It seems it never gets any end of file from the read of the pipe so
> keeps trying to read more. The suggestion to use the -D option works,
> but it really should be the default.
>

That's the nature of named pipes. If there is no writer attached to the pipe
when the reader opens it, the reader suspends immediately. The
reader "wakes up" on the first data written by the writer (which can open
the pipe for writing /after/ the reader opens it for reading), and receives
EOF when the writer closes the pipe.

So, your grep opened the pipe for reading, and found that no writer was
attached to the pipe. This caused the kernel to suspend grep on a pipe
read.

What you need is some process to open the pipe for writing, write to the
pipe, and then /close/ the pipe. The write will "wake up" grep, and the
close will let grep read EOF.


--
Lew Pitcher
Master Codewright & JOAT-in-training | Registered Linux User #112576
Me: http://pitcher.digitalfreehold.ca/ | Just Linux: http://justlinux.ca/
---------- Slackware - Because I know what I'm doing. ------

[unruh]

Well, that would be if I really wanted to read what was written to the
pipe. But grep usually is used to find keywords in already existing
files, not to suck on the end of a preexisting pipe to see if the correct sludge
comes up. Ie, I think -D skip makes far more sense as the default to
grep -r than does the current. Of course if you do not have the -r
option, so that you mention the pipe specifically, or use -D read, then
it is fine, since you presumably know what you are doing and will have
something writing to the other end of the pipe.


>
>

[Richard Kettlewell]

unruh <un...@physics.ubc.ca> writes:
> Well, that would be if I really wanted to read what was written to the
> pipe. But grep usually is used to find keywords in already existing
> files, not to suck on the end of a preexisting pipe to see if the
> correct sludge comes up. Ie, I think -D skip makes far more sense as
> the default to grep -r than does the current. Of course if you do not
> have the -r option, so that you mention the pipe specifically, or use
> -D read, then it is fine, since you presumably know what you are doing
> and will have something writing to the other end of the pipe.

grep is very often used to read pipes, though the most common case is
almost certainly an anonymous pipe on stdin.

-Dskip does not just affect files found through -r; it also suppresses
named pipes explicitly named on the command line. That surely makes it
unsuitable as a default; it would break POSIX-compliance and any script
that relied on the current behavior.

Nevertheless if you're convinced the default behavior should be changed
you will need to contact the maintainers rather than complaining on
Usenet.

--
http://www.greenend.org.uk/rjk/

[unruh]

On 2011-10-21, Richard Kettlewell <r...@greenend.org.uk> wrote:

> unruh <un...@physics.ubc.ca> writes:
>> Well, that would be if I really wanted to read what was written to the
>> pipe. But grep usually is used to find keywords in already existing
>> files, not to suck on the end of a preexisting pipe to see if the
>> correct sludge comes up. Ie, I think -D skip makes far more sense as
>> the default to grep -r than does the current. Of course if you do not
>> have the -r option, so that you mention the pipe specifically, or use
>> -D read, then it is fine, since you presumably know what you are doing
>> and will have something writing to the other end of the pipe.
>
> grep is very often used to read pipes, though the most common case is
> almost certainly an anonymous pipe on stdin.
>
> -Dskip does not just affect files found through -r; it also suppresses
> named pipes explicitly named on the command line. That surely makes it
> unsuitable as a default; it would break POSIX-compliance and any script
> that relied on the current behavior.

As I said, I believe that the default behaviour with -r should be -D skip
For the regular use of grep (ie without -r, or if the pipe is actually
listed on the command line) the current default is fine. Ie, the default
depends on context, or to put it another way, -r should be a combination
of the current -r plus -D skip unless there is anther -D which alters
that.