<<<No Message Collected>>> [Was Re: SYSERR(root): readqf: cannot open ./df*]

Julian Field mailscanner at ecs.soton.ac.uk
Tue Dec 17 18:42:57 GMT 2002


It looks like both of the current problems (this thread and the
RE: SYSERR(root): readqf: cannot open ./df*
thread) are actually the same problem.

If you got into the situation where there was a qf file and no df file for
a message, then you would either see it failing to open the df file or see
it deliver a message with no body.

"Knutzen, Heinz (DZ-SH)" <Heinz.Knutzen at DZSH.DE> has done some very careful
analysis of the problem he is suffering, and I believe is very close to a
solution. He is currently trying out a fix and will hopefully get back to
me tomorrow to tell me if it worked or not. If it works, then I suspect it
will fix this problem too.

The potential fix (for the brave among you) is to modify SMDiskStore.pm to
add some code to Lock(). Basically, if the tf file exists, then don't try
to lock the message and return undef. You can get the full path of the tf
file from
         $this->{dir} . '/' . $this->{tname}
I'm *not* going to produce a patch for this unless Heinz says that it
solves his problem.

Once I've got these 1 or 2 problems fixed, I will release 4.11.

P.S. Got my new server today. "cat /proc/cpuinfo" lists CPU's 0, 1, 2 and
3. A teensy bit quick :-)

At 15:30 17/12/2002, you wrote:
> > I don't think there is supposed to be any way that you'd have two
> > sendmail precesses running against the queue ID on the input side of
> > sendmail (i.e., receiving a message from a remote MTA). But I believe
> > you can can more than one process dealing with the same message ID on
> > the delivery side. The question is whether this occurs before
> > MailScanner sees the message (which might indicate a sendmail mail
> > problem) or when MailScanner has finished with the message. Since I
> > don't know the hostname of this system it isn't clear to me which side
> > it occurs on. Does the maillog indicate that Mailscanner saw
> > the message
> > ID before or after the sendmail error?
>
>I've done some more investigation (thinking aloud...)
>
>The messages that generate the error in the logs (and the No Message
>Collected in the body) also generate two logs saying they have been sent
>on to our exchange server (should only be one).  Each of these logs is
>timestamped at (or within a few seconds of) the same time, but has a
>different process ID.  Both of these sendmail processes have a parent
>process ID of 1 (ie. they are not children of other sendmail
>processes).  A ps -elf | grep sendmail normally shows that there are only
>two parent sendmail processes (in and out), unless you catch it during one
>of these rogue delivery attempts (took a ps; sleep loop to find
>this).  Both of the suspect sendmail processes have a current time stamp,
>so they are not processess which have been left hanging around.  Doing an
>lsof every second (loop again) until an error is noticed shows that the
>sendmail process which creates the error is trying to deliver mail from
>mqueue.in not mqueue!!!!!  I think this is the problem(!) but I can't find
>what might be causing this (and why it only affects mail coming into our
>domains).
>
>I've also seen console messages like the following during my hours trying
>to track this down...
>/bin/cat: /var/spool/mqueue.in/dfgBHF4jNF010284: No such file or directory
>
>I originally thought this was unrelated - but I now suspect that
>mailscanner and sendmail are racing each other to grab messages from the
>mqueue.in queue.  I'm guessing that for each mail recieved one of four
>things happens...
>1) Mailscanner sees the mail quickly and processes it normally
>2) Sendmail sees the mail quickly and delivers it without being scanned
>3) Both see it around the same time, mailscanner trys to process and
>sendmail trys to deliver, but mailscanner picks up the body before
>sendmail causing sendmail to replace the body with '<<<No Message
>Collected>>>' and log an error.  The outgoing sendmail alo attempts to
>deliver the message (after scanning) but it is silently discarded by the
>Exchange server which incoming mail is forwarded to [Big guess there!].
>4) Both see it around the same time, mailscanner trys to process and
>sendmail trys to deliver, but sendmail gets the body first causing
>mailscanner to log an error to the console when it trys to cat the file.
>
>This is all conjecture though - does anyone else have any theorys, or
>ideas what could be causing this behaviour?
>
>
>
>BMRB International
>http://www.bmrb.co.uk +44 (0)20 8566 5000
>________________________________________________________
>
>This message (and any attachment) is intended only for the recipient and
>may contain confidential and/or privileged material. If you have received
>this in error, please contact the sender and delete this message
>immediately. Disclosure, copying or other action taken in respect of this
>email or in reliance on it is prohibited. BMRB International Limited
>accepts no liability in relation to any personal emails, or content of any
>email which does not directly relate to our business.

--
Julian Field
www.MailScanner.info
MailScanner thanks transtec Computers for their support



More information about the MailScanner mailing list