Ok,
I'm happy to report I found a solution to the note I sent out last week.
The problem was not that the file in mess was not going away quick enough,
but that the file was not being created quick enough;-) That is, the
file in mess grows as the data comes off the net and the message is built.
But - if the email is large enough, and the rate of data transfer is slow
enough, the file appears to be sitting there for a while. In our case,
the message was of large size, and was being delivered to our server from
a client over a slow/dialup link... In all cases, when the transfer was
complete, the message was delivered quickly enough and without error.
I had failed to note the size changes in earlier checks, and had never
timed the log entry of delivery to the file growth/ereaseure.
steve
--
Steven Tylock <[EMAIL PROTECTED]>
Questra Corporation, (716) 381-0260 x521
-----
Steve Tylock wrote:
>
> I'm looking for info and have an offer to make - We have Netsaint running
> here to monitor servers / services (plug - http://www.netsaint.org/) and
> we wrote a very small plugin to check the queue of mail messages sitting
> on the servers.
>
> I would be happy to provide this to anyone looking to do a similar thing.
>
> The problem - 'phantom' qmail-qstat responses.
>
> The qmail archives have a few messages about determining how many messages
> are in the queue from back a ways, but I didn't find any touching on this:
>
> qmail-qstat looks at 'messages in queue' by looking for files in the
> directories queue/mess/*.
>
> But - we seem to have a condition (relatively infrequently, but often
> enough to cause a stir) - where a file is left in this directory <after>
> the message has been delivered. (log confirms delivery, no error)
>
> That is, every other file with the same name from that message is gone,
> but the mess file remains for some period of time. 0-60 minutes later,
> the file is removed.
>
> The best I have been able to guess is that some program is holding onto
> an inode, the file is really left there and cleaned up later when it is
> used again, or we have some local bug.
>
> Other info - qmail 1.0.3, Linux 2.2.18, MDA is procmail.
> (I'd offer more direct info, but it isn't happening right now...-)
> [I started this message in January and waited - I'm attaching an 'ls -lr'
> on the queue directory showing 2 left over files in 'mess']
>
> I could work around this by changing the way we look for messages in the
> queue, or fix this. (and am somewhat thinking I'll see a response -
> "your site gets to an empty queue!-)" ((Note - we use the inside the
> firewall queue & outside the firewall queue - the inside server should
> always get back to a nothing in the queue state. It delivers locally
> or gives the messages to the other server to deliver))
>
> any help or advice appreciated,
> steve
> --
> Steven Tylock <[EMAIL PROTECTED]>
> Questra Corporation, (716) 381-0260 x521
