** -----Original Message-----
** From: Mark [mailto:[EMAIL PROTECTED]]
** Sent: Friday, June 08, 2001 11:14 AM
** To: [EMAIL PROTECTED]
** Subject: Re: qmail-remote (cry wolf?)
**
**
** > processed those 1500 messages in less than 30 minutes.
** However, it left
** > behind another handfull of stuck qmail-remote processes.
** Other messages
** > were undeliverable and left in the queue, and still others
** were sent back to
** > sender with permanent errors.
**
** What do you mean by "stuck"? Do you mean they *never* go away - even
** after a day or two? As others have pointed out, a slow delivery can
** take a long, long time. That's not necessarily a problem, that's just
** the way it is.
Yes, I've had qmail-remote processes sit there for weeks. I think that
instead of killing them off wholesale, I'll pick one or two processes and
see just how long they'll hang around. I'll post weekly updates if there's
any interest.
I keep hearing that it might be a very slow delivery. How is this possible
when there isn't any network connection open to the remote host in question,
let alone a connection to it's smtp port.
As far as I can tell, this is a problem between qmail-remote and the kernel.
This is happening on multiple operating systems, so that leads me to believe
that this is not an OS bug.
**
** To find out a bit more about what a "stuck" qmail-remote is doing, you
** may want to ktrace it and show us the output. Find the process id of the
** stuck qmail-remote and then as root go: ktrace -p thepid
**
** Leave that running for at least an hour and show us the output. Yes, I
** mean at least an hour.
**
Ok, I meant to come back in an hour and stop the trace, but after running
ktrace for 9 hours (while I slept), the resulting ktrace.out file is exactly
0 bytes in length. Would you like me to send a copy? <g>
I did verify the behavior of ktrace, and a ktrace on qmail-send generated
tons of data within seconds. ktrace is working.
Anything else y'all would like me to lok at?
--
Troy Settle
Pulaski Networks
540.994.4254