[Dovecot] Dovecot LDA (deliver) stopped working

[falz]

On Jan 25, 2008 9:22 AM,  <tomas at tuxteam.de> wrote:
> > Postfix people suggested placing a wrapper script for mailbox_command,
> > which I did, and have it log to a text file, so I do know that deliver
> > is being called.
>
> To get you right here: the wrapper is being called by Postfix, right?

Yes, postfix calls a wrapper. The wrapper is a shell script that calls
deliver. This is the wrapper. $LOGNAME comes from postfix, it's a
built in variable it populates as the local username:

#!/bin/sh
DELIVER=/usr/local/libexec/dovecot/deliver
DATE=`date`
echo "==" >> /tmp/foo.txt
echo $DATE >> /tmp/foo.txt
echo $USER >> /tmp/foo.txt
$DELIVER -d "$LOGNAME"
echo $DATE >> /tmp/foo.txt



> >                  However, although I have LDA debug logging on, and it
> > DID log prior to this, when postfix supposedly calls deliver, dovecot
> > does NOT log anything.
>
> ...and LDA (called from the wrapper) doesn't run (or doesn't run to the
> point of logging anything).

Well, it's hard for me to tell. I know for sure that the wrapper ran,
as I get my temp log does get the tiemstamp that's before/after
deliver. However, I guess I dont know the best way to log the
output/exit status of the deliver command.


> >                         It DOES however log if I call deliver from any
> > account (root or not) from the command line (ls / | /path/to/deliver
> > -d localaccountname). Any way I can debug this further? I would assume
> > that deliver would log something even if it's called, but it appears
> > that it does not.
>
> That's rather bizarre. I would up the verbosity of the wrapper (f.ex.
> putting a couple of line 'which /path/to/deliver' or 'ldd /path/to/deliver'
> - -- or even 'strace /path/to/deliver'). Something in the environment must
> be different to the command lines, right?

Hmm, perhaps I should somehow log the entire status of SETENV or
something. What I probably really need to do is figure out the
appropriate pipes after the deliver line to find out if it's spitting
anything back to stderr or something. This is usually.. >> 2&1 or
something similar? Anyone have suggestions for that?

--falz