On Jan 25, 2008 9:22 AM, tomas@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 itDID 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 anyaccount (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