For Programmers: Free Programming Magazines  


Home > Archive > PERL Miscellaneous > March 2005 > Broken pipe problem? If so, why?









You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

 

Author Broken pipe problem? If so, why?
malgosia askanas

2005-03-28, 3:58 pm

I have a mail-handling program written in Perl. It gets passed a mail message,
reads the header, does some processing, and exits. The code for reading
the header is:

$/ = ''; # paragraph mode
$header = <>;

I am invoking this program in a pipe from procmail. For some messages (I
believe, for very large ones) I get the message "Error while writing to
<progname>" in the procmail log. I would be inclined to believe that it's
a broken pipe problem, but if so, why does its occurrence depend on the
message size? The program reads only the header for _all_ messages,
independent of size - yet in a vast majority of cases, procmail does not
complain. Can you advise?


Many thanks in advance,
-malgosia
Big and Blue

2005-03-28, 3:58 pm

malgosia askanas wrote:
>
> $/ = ''; # paragraph mode
> $header = <>;
>
> I am invoking this program in a pipe from procmail. For some messages (I
> believe, for very large ones) I get the message "Error while writing to
> <progname>" in the procmail log. I would be inclined to believe that it's
> a broken pipe problem, but if so, why does its occurrence depend on the
> message size? The program reads only the header for _all_ messages,
> independent of size - yet in a vast majority of cases, procmail does not
> complain. Can you advise?


The fact that you "only" read the header is the problem (but reading
all of it is not necessarily the solution).

procmail is piping the message to you (can't you configure procmail
just to send teh header?). If the entire message is small enough to fit
into the buffer of a pipe (usually 8kB?) then it will write it all and
things are OK. If it is larger than this though a problem occurs - you
only read the start of the then close the pipe (by exiting). Since you
have closed the pipe while procmail still has it open *it* gets sent a SIGPIPE.

So, you have to look at the procmail config options and:

1) get it to only send headers - if possible only get it to send
information you are interested in.
2) tell it to ignore SIGPIPE if possible

if 2) is not possible then you should read *everything* (but just ignore
the parts aftre the bit you really want).




--
Just because I've written it doesn't mean that
either you or I have to believe it.
xhoster@gmail.com

2005-03-28, 3:58 pm

ma@panix.com (malgosia askanas) wrote:
> I have a mail-handling program written in Perl. It gets passed a mail
> message, reads the header, does some processing, and exits. The code for
> reading the header is:
>
> $/ = ''; # paragraph mode
> $header = <>;
>
> I am invoking this program in a pipe from procmail. For some messages (I
> believe, for very large ones) I get the message "Error while writing to
> <progname>" in the procmail log. I would be inclined to believe that
> it's a broken pipe problem, but if so, why does its occurrence depend on
> the message size? The program reads only the header for _all_ messages,
> independent of size - yet in a vast majority of cases, procmail does not
> complain. Can you advise?


Since your Perl program is only reading the header, it must be terminating
while there is still stuff to be read. For short messages, all that stuff
to be read fits in the buffer, so the other end of the pipe doesn't notice.
But for large messages, when the Perl end of the pipe exits the other end
of the pipe gets upset because it is now trying to write to something that
no longer exists. Or something like that.

Xho

--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
Sponsored Links







Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive

Copyright 2008 codecomments.com