On Thu, 24 Feb 2000, Len Budney wrote:
> "Peter Samuel" <[EMAIL PROTECTED]> wrote:
> > On 24 Feb 2000, D. J. Bernstein wrote:
> >
> > > Peter Samuel writes:
> > > > Under certain conditions it can leave the queue in a corrupt state.
> > >
> > > No, it can't. See INTERNALS in the qmail package for the complete story.
> >
> > I _know_ what INTERNALS says Dan, but try this test and you'll see
> > that it does leave the queue in a corrupt state...qmail-queue exits
> > with a 91 and does NOT unlink the mess or intd file.
>
> That doesn't mean that the queue is ``corrupted''. If todo/INODE exists,
> the message is queued. If not, the message is not queued. Period. Qmail
> returns success to the caller only if the message is queued.
>
> Lots of failures can leave various files in the queue tree--INTERNALS
> discusses that at great length (for Dan). If qmail-queue is killed in
> state S3, both mess/INODE and intd/INODE will exist--but the message is
> not queued.
>
> That's what qmail-clean is for. It's called by qmail-send to clean up
> any lint in the queue tree. Note, though, that this takes at least 36
> hours. qmail-send doesn't delete younger files, because they might
> represent a message presently being queued. It's all documented in
> INTERNALS.
I know that. My choice of words was poor. I shouldn't have said
"corrupt". I'm also aware that qmail-clean will reap stray files after
36 hours.
I was giving an example of why qmail-qstat and qmail-qread can
sometimes give inconsistent results, and highlighting an inconsistent
behaviour of qmail-queue:
- qmail-queue cleans up if the evenlope details are invalid in
most, but not all cases.
Sorry for the confusion.
Regards
Peter
----------
Peter Samuel [EMAIL PROTECTED]
Technical Consultant or at present:
eServ. Pty Ltd [EMAIL PROTECTED]
Phone: +61 2 9206 3410 Fax: +61 2 9281 1301
"If you kill all your unhappy customers, you'll only have happy ones left"
