Re: [exim] Debugging autoreply transport

Páxina inicial
Borrar esta mensaxe
Responder a esta mensaxe
Autor: Philip Hazel
Data:  
Para: Richard Hoyle
CC: exim-users
Asunto: Re: [exim] Debugging autoreply transport
On Wed, 16 Aug 2006, Richard Hoyle wrote:

> I've been experimenting with vacation msgs, using an accept
> router, and an autoreply transport, which all seem pretty
> standard. The message routes fine, and the conditions in the
> accept router all seem to be satisfied, but when debugging
> the whole lifetime of the message, I got errors when the
> child delivery process for the autoreply transport is called.
> This _only_ happens in debugging mode. The errors were similar
> to the following:
>
> 826 cwd=/home/emma 8 args: /usr/exim/bin/exim -d=0xfbbd5cfd -t -oem -oi -f <>
> -E1GDQC6-0000D5-GT
> exim: debugging permission denied

        ^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is a situation in which there is a problem with debugging. When you 
run a vacation transport as a user other than root or exim (which is 
quite often the case), and the user is not an Exim admin user, the 
autoreply process is not privileged enough to request debugging when it
calls Exim to submit the message.


> 825 vacation_reply transport succeeded
> 825 search_tidyup called
> 818 vacation_reply transport returned DEFER for emma@???
> 818 added retry item for T:emma@???: errno=0 more_errno=0 fla
> gs=0
> 818 post-process emma@??? (1)
> 818 LOG: MAIN
> 818 == emma@??? R=user_vacation T=vacation_reply defer (0):
> Failed to send message from vacation_reply transport (1)
> 818 >>>>>>>>>>>>>>>> deliveries are done >>>>>>>>>>>>>>>>
>
> Does this mean that I cannot debug this transport at all if it
> runs as an unprivileged user?


If it is not an Exim admin user, then, yes, I'm afraid.

> Why does the transport think it succeeded, and why is the vacation msg
> not put on the queue for later delivery?


In this case "succeeded" means that it tried to do its job without
crashing or hitting any kind of error. The subprocess ended normally.
However, it encountered a problem and so returned "DEFER". (This is like
an smtp transport succeeding - i.e. running correctly - but being unable
to connect to a remote host.)

What the problem was is, unfortunately, unclear. If you can run the
transport as an Exim admin user, it should be able to request debugging
from the called submission Exim, so perhaps then you'll be able to see
what is going on.

-- 
Philip Hazel            University of Cambridge Computing Service
Get the Exim 4 book:    http://www.uit.co.uk/exim-book