Konstantin Boyandin <[EMAIL PROTECTED]> writes: > >> I had to create the ~/.tmda/pending (I didn't find any hints > >> on .tmda contents in installation document), > > TL> tmda-filter creates ~/.tmda/pending the first time it needs it. > > In my case it didn't. Instead, in ~/TMDA_DELIVERY_FAILURE it > was written that TMDA can't find the 'pending' directory and aborts.
Hmm. I've just discovered some relatively new code that misbehaves in very rare edge cases. I think you hit one of those. I'll get a fix in for this, since that problem should never occur. > >> From maillog: > >> > >> Sep 11 00:54:36 zaurum sendmail[7317]: h8B7sYc07315: SYSERR(root): mailer prog > >> died with signal 11 > >> Sep 11 00:54:36 zaurum sendmail[7317]: h8B7sYc07315: to="| /usr/bin/procmail", > >> ctladdr=<[EMAIL PROTECTED]> (502/503), delay=00:00:01, xdelay=00:00:00, > >> mailer=prog, pri=30019, dsn=4.0.0, > >> stat=Deferred: prog mailer (/usr/sbin/smrsh) exited with EX_TEMPFAIL > > TL> When TMDA runs into an unrecoverable problem, it exits with errorcode > TL> 75 (EX_TEMPFAIL). It writes a Python stack trace into LOGFILE_DEBUG > TL> (if you have defined that) or ~/TMDA_DELIVERY_FAILURE. If you can > TL> post the contents of that file, we can see what's dying. > > It doesn't create this file! All I have are the two records in > maillog. Nothing else. If the ~/TMDA_DELIVERY_FAILURE were available, > I would continue to investigate the problem myself. > > TMDA simply dies, leaving nothing to judge why. This is why I > asked what I should do to force TMDA to create as much trace info as > possible. You said above that is has, on occasion, created this file, so I'm guessing that it's not a permissions problem. I have no idea why it wouldn't create the file. However, in the case when it can't create the file, it writes the problem report to standard output. Some MTAs trap the standard output of the delivery programs they run and write that output to their log files. Apparently Sendmail doesn't do this. You might try redirecting the output of tmda-filter to a temporary file (when you invoke it from procmail), sending a test message and seeing if you can trap the error report that way. If it doesn't make sense, please post it. > >> The previous problem was 'error 99' (cured by modifying > >> .procmailrc the way it looks now). > > TL> You won't get an exit code of 99 if you don't use the -p flag. > > In the original setup, I didn't use '-p' flag. Sendmail has > complained that the mailer has returned exit code 99. The only time tmda-filter returns 99 is if MAIL_TRANSFER_AGENT is set to "qmail" or if the '-p' flag is used. I had assumed you had set MAIL_TRANSFER_AGENT = "sendmail" in either your local config or in /etc/tmdarc. If this is not the case, you will want to do that (it defaults to "qmail"). > >> How can this current problem be solved (dying with signal 11)? > > TL> It depends on what's causing the signal 11. The stack trace may > TL> provide us with more information. > > The problem is to create the stack trace dump. Hopefully you can get the redirection I mentioned above to work. > The major problem, for me, presonally, with TMDA is that the > installation directions are scattered over many places of > documentation. That is about 'pending' directory etc. A sample setup, > including the contents of all control files, wouldn't harm. There are simply too many variables to provide sample setups for each possible environment. Not to mention that the setups would be at least somewhat different depending on the MTA in use. The pending problem is a bug and needs to be fixed. It's not supposed to work that way! Tim _____________________________________________ tmda-users mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-users
