Re: [exim-dev] Pipe transport and 64kB limit due to wrong (?…

Startseite
Nachricht löschen
Nachricht beantworten
Autor: Phil Pennock
Datum:  
To: Christoph Schulz
CC: exim-dev
Betreff: Re: [exim-dev] Pipe transport and 64kB limit due to wrong (?) SIGPIPE handling
On 2012-06-24 at 12:46 +0200, Christoph Schulz wrote:
> As you say, it is the _child_ exim process executing my script, so the
> change may be/is really relevant to my problem. It would be very
> strange if changing the handling of SIGPIPE in the _parent_ process
> influenced the execution of the script, wouldn't it?


I meant child, as opposed to before the fork; so there's no difference
in execution path, it's only SIGPIPE that was changed, we're not using
signal-driven I/O and really the changes are entirely isolated to the
environment within which the child runs.

> #
> # format and save incoming mail
> #
>
> EMAIL_FILE="${E2S_EMAIL_FILE_STEM}-${EMAIL_ID}"
> EMAIL_FILE_RAW="${E2S_EMAIL_FILE_STEM}-${EMAIL_ID}.raw"
>
> UMASK=`umask`
> umask 0077
> tee "${EMAIL_FILE_RAW}" | e2sformat > "${EMAIL_FILE}"
>
> === %< ===
>
> There is a little signal handling with "trap" earlier on but this does
> not do anything with the SIGPIPE signal:


You don't mention your OS. On both BSD and Linux, SIGPIPE is signal 13.
You trap signal 13.

> trap "exit 1" 1 2 3 13 15


Per sh(1):
----------------------------8< cut here >8------------------------------
                      The trap command has no effect on signals that were
             ignored on entry to the shell.
----------------------------8< cut here >8------------------------------


So, in the old Exim, SIGPIPE was ignored, the trap command has no
effect, and so SIGPIPE continued to be ignored.

In the new Exim, SIGPIPE is not ignored, the trap command has an effect
and you explicitly abort your shell script whenever you write to a pipe
where the reader stops reading and closes the fd it has open on the
pipe.

You should probably change that line to be:

trap "exit 1" 1 2 3 15
trap "" 13

I don't know what the e2sformat command does, but I suspect that it's
only taking some of the input for a synopsis of some kind, and stops
after 64kB? That causes a SIGPIPE in the shell; that normally causes
only the command writing to the pipe to die, but you've *explicitly*
told the shell to exit when this happens.

I think that Exim fixing its bug exposed a dormant bug in your script.
Oww, that's unpleasant. I feel your pain.

-Phil