ignore pipe(8) return code (don't bounce) ?

[Geert Hendrickx]

Hi,

is it possible to ignore the return value of a script invoked via pipe(8),
ie., not send a bounce when it returns a value greater than zero?

Thanks,

        Geert

[Victor Duchovni]

On Sun, May 04, 2008 at 08:59:09PM +0200, Geert Hendrickx wrote:

> is it possible to ignore the return value of a script invoked via pipe(8),
> ie., not send a bounce when it returns a value greater than zero?

Use a wrapper script that always returns zero.

        #! /bin/sh

        /some/broken/script/that/fails/spuriously
        exit 0

Your problem description and goals are rather vague, so the answer cannot
be much more detailed.

--
        Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:[hidden email]?body=unsubscribe%20postfix-users>

If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

[Geert Hendrickx]

On Sun, May 04, 2008 at 03:38:57PM -0400, Victor Duchovni wrote:

> On Sun, May 04, 2008 at 08:59:09PM +0200, Geert Hendrickx wrote:
>
> > is it possible to ignore the return value of a script invoked via pipe(8),
> > ie., not send a bounce when it returns a value greater than zero?
>
> Use a wrapper script that always returns zero.
>
> #! /bin/sh
>
> /some/broken/script/that/fails/spuriously
> exit 0
>
> Your problem description and goals are rather vague, so the answer cannot
> be much more detailed.

The script is a Perl script that sends auto-responses.  It has some "die"
statements when it can't connect to its database etc.  But I never want
this script to cause any bounces to the sender, the auto-responses should
be considered "best effort" (ignore if fail).  The above shell code won't
work since the message has to be passed on to stdin of the wrapped script,
but perhaps "cat stdin | /path/to/script" and "exit 0" will work.

Thanks for the suggestion, but is there no solution in Postfix itself?

        Geert

[Victor Duchovni]

On Sun, May 04, 2008 at 09:50:15PM +0200, Geert Hendrickx wrote:

> On Sun, May 04, 2008 at 03:38:57PM -0400, Victor Duchovni wrote:
> > On Sun, May 04, 2008 at 08:59:09PM +0200, Geert Hendrickx wrote:
> >
> > > is it possible to ignore the return value of a script invoked via pipe(8),
> > > ie., not send a bounce when it returns a value greater than zero?
> >
> > Use a wrapper script that always returns zero.
> >
> > #! /bin/sh
> >
> > /some/broken/script/that/fails/spuriously
> > exit 0
> >
> > Your problem description and goals are rather vague, so the answer cannot
> > be much more detailed.
>
>
> The script is a Perl script that sends auto-responses.  It has some "die"
> statements when it can't connect to its database etc.  But I never want
> this script to cause any bounces to the sender, the auto-responses should
> be considered "best effort" (ignore if fail).  The above shell code won't
> work since the message has to be passed on to stdin of the wrapped script,
> but perhaps "cat stdin | /path/to/script" and "exit 0" will work.

The "cat stdin" is entirely unecessary, and inefficient. How is "cat"
able to read standard input and the script not?

> Thanks for the suggestion, but is there no solution in Postfix itself?

The solution is to never return a non-zero exit code. You can put a big
eval block around your code in Perl, to avoid having to wrap it in a shell
script.

        eval {
            ... main program of script ...
        };
        # syslog("warning", "%s", $@) if ($@); # if desired

--
        Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:[hidden email]?body=unsubscribe%20postfix-users>

If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

[Geert Hendrickx]

On Sun, May 04, 2008 at 03:58:20PM -0400, Victor Duchovni wrote:
> On Sun, May 04, 2008 at 09:50:15PM +0200, Geert Hendrickx wrote:
> The "cat stdin" is entirely unecessary, and inefficient. How is "cat"
> able to read standard input and the script not?
>
> > Thanks for the suggestion, but is there no solution in Postfix itself?
>
> The solution is to never return a non-zero exit code.


What if it is compiled 3rd party code which you can't modify?  Is there no
way in Postfix to say "silently ignore all errors and never bounce for this
particular transport" ?


> You can put a big eval block around your code in Perl, to avoid having to
> wrap it in a shell script.
>
> eval {
>    ... main program of script ...
> };
> # syslog("warning", "%s", $@) if ($@); # if desired


Thanks, I'll try that.

        Geert

[mouss-2]

Geert Hendrickx wrote:

> On Sun, May 04, 2008 at 03:58:20PM -0400, Victor Duchovni wrote:
>  
>> On Sun, May 04, 2008 at 09:50:15PM +0200, Geert Hendrickx wrote:
>> The "cat stdin" is entirely unecessary, and inefficient. How is "cat"
>> able to read standard input and the script not?
>>
>>    
>>> Thanks for the suggestion, but is there no solution in Postfix itself?
>>>      
>> The solution is to never return a non-zero exit code.
>>    
>
>
> What if it is compiled 3rd party code which you can't modify?  Is there no
> way in Postfix to say "silently ignore all errors and never bounce for this
> particular transport" ?
>  

use a wrapper. Viktor said

        #! /bin/sh

        /some/broken/script/that/fails/spuriously
        exit 0

>
>  
>> You can put a big eval block around your code in Perl, to avoid having to
>> wrap it in a shell script.
>>
>> eval {
>>    ... main program of script ...
>> };
>> # syslog("warning", "%s", $@) if ($@); # if desired
>>    
>
>
> Thanks, I'll try that.
>
> Geert
>
>
>  

[Victor Duchovni]

On Sun, May 04, 2008 at 10:20:14PM +0200, Geert Hendrickx wrote:

> On Sun, May 04, 2008 at 03:58:20PM -0400, Victor Duchovni wrote:
> > On Sun, May 04, 2008 at 09:50:15PM +0200, Geert Hendrickx wrote:
> > The "cat stdin" is entirely unecessary, and inefficient. How is "cat"
> > able to read standard input and the script not?
> >
> > > Thanks for the suggestion, but is there no solution in Postfix itself?
> >
> > The solution is to never return a non-zero exit code.
>
> What if it is compiled 3rd party code which you can't modify?  Is there no
> way in Postfix to say "silently ignore all errors and never bounce for this
> particular transport" ?

Yes, the way to do this in Postfix is to enclose the broken code in a
wrapper that runs the broken code, and then always returns 0.

--
        Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:[hidden email]?body=unsubscribe%20postfix-users>

If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

[Ralf Hildebrandt]

* Geert Hendrickx <[hidden email]>:

> The script is a Perl script that sends auto-responses.  It has some "die"
> statements when it can't connect to its database etc.

In that case it should die with a TEMFPAIL

--
Ralf Hildebrandt ([hidden email])          [hidden email]
Postfix - Einrichtung, Betrieb und Wartung       Tel. [phone]
http://www.arschkrebs.de
Profanity is the one language all programmers know best.

[Geert Hendrickx]

On Sun, May 04, 2008 at 05:49:16PM -0400, Victor Duchovni wrote:
> Yes, the way to do this in Postfix is to enclose the broken code in a
> wrapper that runs the broken code, and then always returns 0.

The code isn't *broken*, it sometimes returns an error because it can't
do its job (database unavailable or other), but I just want the system
to ignore these errors because a failure of sending the auto-reply isn't
critical.

But I got the message by now, I'm using a wrapper shell script. :-)

        Geert

[Geert Hendrickx]

On Mon, May 05, 2008 at 08:43:31AM +0200, Ralf Hildebrandt wrote:
> * Geert Hendrickx <[hidden email]>:
>
> > The script is a Perl script that sends auto-responses.  It has some
> > "die" statements when it can't connect to its database etc.
>
> In that case it should die with a TEMFPAIL


Which exit codes are considered temporary?

Thanks,

        Geert

[Ralf Hildebrandt]

* Geert Hendrickx <[hidden email]>:

> On Mon, May 05, 2008 at 08:43:31AM +0200, Ralf Hildebrandt wrote:
> > * Geert Hendrickx <[hidden email]>:
> >
> > > The script is a Perl script that sends auto-responses.  It has some
> > > "die" statements when it can't connect to its database etc.
> >
> > In that case it should die with a TEMFPAIL
>
>
> Which exit codes are considered temporary?

EX_TEMPFAIL :) (it's 75, if I'm not mistaken)

--
Ralf Hildebrandt ([hidden email])          [hidden email]
Postfix - Einrichtung, Betrieb und Wartung       Tel. [phone]
http://www.arschkrebs.de
Failure is not an option.
It comes bundled with your Microsoft product.

[Victor Duchovni]

On Mon, May 05, 2008 at 10:50:04AM +0200, Geert Hendrickx wrote:

> On Mon, May 05, 2008 at 08:43:31AM +0200, Ralf Hildebrandt wrote:
> > * Geert Hendrickx <[hidden email]>:
> >
> > > The script is a Perl script that sends auto-responses.  It has some
> > > "die" statements when it can't connect to its database etc.
> >
> > In that case it should die with a TEMFPAIL
>
>
> Which exit codes are considered temporary?

I thought you wanted to skip delivery on error, not try again later...

See the pipe(8) manpage:

    DIAGNOSTICS
       Command exit status  codes  are  expected  to  follow  the  conventions
       defined in <sysexits.h>.  Exit status 0 means normal successful comple-
       tion.

       Postfix version 2.3 and later support RFC  3463-style  enhanced  status
       codes.   If  a  command terminates with a non-zero exit status, and the
       command output begins with an enhanced status code,  this  status  code
       takes precedence over the non-zero exit status.

The script below will defer all mail (on systems whose <sysexits.h> is
sufficiently similar):

    perl -e '
        use constant {
            EX_OK           => 0,   #  successful termination
            EX_USAGE        => 64,  #  command line usage error
            EX_DATAERR      => 65,  #  data format error
            EX_NOINPUT      => 66,  #  cannot open input
            EX_NOUSER       => 67,  #  addressee unknown
            EX_NOHOST       => 68,  #  host name unknown
            EX_UNAVAILABLE  => 69,  #  service unavailable
            EX_SOFTWARE     => 70,  #  internal software error
            EX_OSERR        => 71,  #  system error (e.g., can't fork)
            EX_OSFILE       => 72,  #  critical OS file missing
            EX_CANTCREAT    => 73,  #  can't create (user) output file
            EX_IOERR        => 74,  #  input/output error
            EX_TEMPFAIL     => 75,  #  temp failure; user is invited to retry
            EX_PROTOCOL     => 76,  #  remote error in protocol
            EX_NOPERM       => 77,  #  permission denied
            EX_CONFIG       => 78,  #  configuration error
        };
        warn "4.3.0 Try again later\n";
        exit(EX_TEMPFAIL);
    '

--
        Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:[hidden email]?body=unsubscribe%20postfix-users>

If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.