> That text has nothing to do with the exit code (the "null 0"). It
> comes from a printf() statement in the code that prints out the value
> of the null pointer as an integer (which will always be 0).
>
> Hmm, I just realized that any output probably makes exim consider the
> delivery to have failed, but since you still get the seg fault message
> I don't think that is relevant.
>
> Try using a shell script like this instead then (untested) :
It seems not to depend on the exit code only. This one works fine:
#!/bin/sh
if [ "$1" == "" ]; then
logger "should be delivered"
exit 0
else
logger "should stay in q"
exit 139
fi
while this one does not work correctly:
#!/bin/sh
/bin/cat - | /tmp/crash.bin $1
ECODE=$?
logger "crash exit code is $ECODE"
if [ $ECODE == 139 ] ; then
logger "should stay in q"
exit 139
else
logger "should be delivered"
exit 0
fi
Both should actually give the same result. As you stated this might be of the
output of the signal handler. So I tried:
#!/bin/sh
(
/bin/cat - | /tmp/crash.bin $1
) 1>/dev/null 2>/dev/null
ECODE=$?
logger "crash exit code is $ECODE"
if [ $ECODE == 139 ] ; then
logger "should stay in q"
exit 139
else
logger "should be delivered"
exit 0
fi
Which seem to give the exspected result. I looked again in the FM and found I
should set preferably:
temp_errors = 139
return_fail_output = true
return_output = false
unfortunately this seems only to include stdout *NOT* stderr so I created a
wrapper script that does the trick:
#!/bin/sh
(
/bin/cat - | /tmp/crash.bin $*
) 2>/dev/null
Shouldn't return_fail_output include stderr?
--
Torsten
