qmail-remote (cry wolf?)

Sorry, but I'm not all comfortable with this... There's been 4 similar reports of qmail-remote not behaving properly to this list during the last month. http://www.ornl.gov/its/archives/mailing-lists/qmail/2001/05/msg00558.html http://www.ornl.gov/its/archives/mailing-lists/qmail/2001/05/msg013

Re: qmail-remote (cry wolf?)

On Thu, Jun 07, 2001 at 07:36:53PM +0200, Jörgen Persson allegedly wrote: > Sorry, but I'm not all comfortable with this... > > There's been 4 similar reports of qmail-remote not behaving properly to > this list during the last month. > > http://www.ornl.gov/its/archives/mailing-lists/qmail/200

Re: qmail-remote (cry wolf?)

> What are the probabilities of the Sendmail server being the one causing > the problems? What if the mail admin of mg.hk5.outblaze.com has used > some sort of patch that is causing qmail-remote's to hang? Has anyone > communicated with outblaze.com's postmaster? There is nothing a remote system

Re: qmail-remote (cry wolf?)

On Thu, Jun 07, 2001 at 07:36:53PM +0200, Jörgen Persson wrote: > http://www.ornl.gov/its/archives/mailing-lists/qmail/2001/05/msg00558.html rethat 6.2, outblaze.com > http://www.ornl.gov/its/archives/mailing-lists/qmail/2001/05/msg01332.html rethat 6.2, outblaze.com > http://www.ornl.gov/it

Re: qmail-remote (cry wolf?)

J=F6rgen Persson <[EMAIL PROTECTED]> wrote: >There's been 4 similar reports of qmail-remote not behaving properly t= o >this list during the last month.=20 > >http://www.ornl.gov/its/archives/mailing-lists/qmail/2001/05/msg00558.= html >http://www.ornl.gov/its/archives/mailing-lists/qmail/2001/05

Re: qmail-remote (cry wolf?)

On Thu, Jun 07, 2001 at 07:36:53PM +0200, Jörgen Persson wrote: > Sorry, but I'm not all comfortable with this... > > There's been 4 similar reports of qmail-remote not behaving properly to > this list during the last month. > > http://www.ornl.gov/its/archives/mailing-lists/qmail/2001/05/msg00

Re: qmail-remote (cry wolf?)

Jörgen Persson wrote: > > Sorry, but I'm not all comfortable with this... > > There's been 4 similar reports of qmail-remote not behaving properly to > this list during the last month. > We still haven't been able to help any of them... > > This doesn't look like a coincidence to me since two

Re: qmail-remote (cry wolf?)

Mark et. al. - It *is* possible, though, for qmail-remote to move slowly enough that it appears to hang (yes, even for hours or days). timeoutremote applies to every read() and write() - in the very worst case, each of these system calls might move only a single byte. Consider a 5000 byte messa

Re: qmail-remote (cry wolf?)

On Thu, Jun 07, 2001 at 04:39:25PM -0700, David Lowe allegedly wrote: > Mark et. al. - > > It *is* possible, though, for qmail-remote to move slowly enough that it > appears to hang (yes, even for hours or days). timeoutremote applies to > every read() and write() - in the very worst case, each

Re: qmail-remote (cry wolf?)

On Thu, Jun 07, 2001 at 10:43:27PM +0300, Mike Jackson wrote: > What are the probabilities of the Sendmail server being the one causing > the problems? What if the mail admin of mg.hk5.outblaze.com has used > some sort of patch that is causing qmail-remote's to hang? Which means it might be expl

RE: qmail-remote (cry wolf?)

nt: Thursday, June 07, 2001 6:00 PM ** To: [EMAIL PROTECTED] ** Subject: Re: qmail-remote (cry wolf?) ** ** ** > What are the probabilities of the Sendmail server being the ** one causing ** > the problems? What if the mail admin of mg.hk5.outblaze.com has used ** > some sort of patch that

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

Re: qmail-remote (cry wolf?)

One more time, I did tcpdump and strace on stuck qmail-remote for over an hour. strace shows that qmail-remote is stuck on: 'read(3', and tcpdump shows that nothing comes in. On Fri, Jun 08, 2001 at 03:13:54PM +, Mark wrote: > > processed those 1500 messages in less than 30 minutes. However

Re: qmail-remote (cry wolf?)

On Fri, Jun 08, 2001 at 03:51:18PM -0400, Yevgeniy Miretskiy allegedly wrote: > One more time, > > I did tcpdump and strace on stuck qmail-remote for over an hour. > strace shows that qmail-remote is stuck on: 'read(3', and tcpdump shows > that nothing comes in. One more time. Then it's an OS bu

Re: qmail-remote (cry wolf?)

On Fri, Jun 08, 2001 at 09:47:16PM +, Mark wrote: > Then it's an OS bug. > > qmail-remote only gets to the read() if the OS (via select() ) says > that the read will not block. Ergo, the OS is lying. If it's OS bug, anybody heard/knows of such severe network related bug in RedHat 6.2? What

Re: qmail-remote (cry wolf?)

Yevgeniy Miretskiy <[EMAIL PROTECTED]> wrote: > On Fri, Jun 08, 2001 at 09:47:16PM +, Mark wrote: > > Then it's an OS bug. > > > > qmail-remote only gets to the read() if the OS (via select() ) says > > that the read will not block. Ergo, the OS is lying. > > If it's OS bug, anybody heard/kn

RE: qmail-remote (cry wolf?)

** -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 handf

Re: qmail-remote (cry wolf?)

On Sat, Jun 09, 2001 at 06:32:55AM -0400, Troy Settle wrote: > 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 inte

Re: qmail-remote (cry wolf?)

I think we may have red-herringed on the OS thing -- if RH6.2, as deployed, had this sort of problem, I think we would have run across it before this, no? The inclusion of a FreeBSD-4.2-STABLE in the mix seems to nix a RH specific bug as well (althought it obviously does not rule it out entirely*)

Re: qmail-remote (cry wolf?)

> > Is it possible that some external devices s.a. > > switch/router/firewall/anything could be causing this problem? > > Yes, very possble. Some firewalls do "transparent" SMTP or POP proxying, and > there have been many bugs in such implementations. No. Regardless of what the other end does,

Re: qmail-remote (cry wolf?)

On Fri, Jun 08, 2001 at 08:11:21PM -0400, Yevgeniy Miretskiy allegedly wrote: > On Fri, Jun 08, 2001 at 09:47:16PM +, Mark wrote: > > Then it's an OS bug. > > > > qmail-remote only gets to the read() if the OS (via select() ) says > > that the read will not block. Ergo, the OS is lying. > >

Re: qmail-remote (cry wolf?)

> As far as I can tell, this is a problem between qmail-remote and the kernel. Correct. > This is happening on multiple operating systems, so that leads me to believe > that this is not an OS bug. But many OSes share TCP/IP implementations or mis-interpretations of the protocol. Many coders of

Re: qmail-remote (cry wolf?)

On Sat, Jun 09, 2001 at 09:05:00AM -0700, Greg White allegedly wrote: > I think we may have red-herringed on the OS thing -- if RH6.2, as > deployed, had this sort of problem, I think we would have run across it > before this, no? The inclusion of a FreeBSD-4.2-STABLE in the mix seems > to nix a R

Re: qmail-remote (cry wolf?)

Greg White writes: > I think we may have red-herringed on the OS thing -- if RH6.2, as > deployed, had this sort of problem, I think we would have run across it > before this, no? Hmmm I wonder. I could do a denial of service attack on qmail-remote by receiving email very, very slowly, a

Re: qmail-remote (cry wolf?)

Russell Nelson <[EMAIL PROTECTED]> wrote: > > Hmmm I wonder. I could do a denial of service attack on > qmail-remote by receiving email very, very slowly, and by sending > email to a server which is guaranteed to be received and guaranteed to > bounce. qmail doesn't keep track of very slow

Re: qmail-remote (cry wolf?)

On Sat, Jun 09, 2001 at 03:11:59PM -0400, Russell Nelson allegedly wrote: > Greg White writes: > > I think we may have red-herringed on the OS thing -- if RH6.2, as > > deployed, had this sort of problem, I think we would have run across it > > before this, no? > > Hmmm I wonder. I could

Re: qmail-remote (cry wolf?)

On Sat, Jun 09, 2001 at 05:58:49PM +, Mark wrote: > It's a bummer that ktrace is like that on FreeBSD. It doesn't show the > *current* system call that the process is sitting on. Conversely, > truss on Solaris does this nicely... But FreeBSD does have a (procfs-based) truss. -- Jos Backus

Re: qmail-remote (cry wolf?)

> Perhaps something like a "maxlifetime" control file for qmail-remote and (Serendipity strikes again - I just posted sample code for this). > qmail-smtpd? At process startup, set an alarm for X seconds -- if the ALRM is > received, abort the connection as gracefully as possible (i.e. try to se

Re: qmail-remote (cry wolf?)

On Sat, Jun 09, 2001 at 01:00:46PM -0700, Jos Backus allegedly wrote: > On Sat, Jun 09, 2001 at 05:58:49PM +, Mark wrote: > > It's a bummer that ktrace is like that on FreeBSD. It doesn't show the > > *current* system call that the process is sitting on. Conversely, > > truss on Solaris does t

Re: qmail-remote (cry wolf?)

On Sat, Jun 09, 2001 at 08:12:03PM +, Mark wrote: > On Sat, Jun 09, 2001 at 01:00:46PM -0700, Jos Backus allegedly wrote: > > On Sat, Jun 09, 2001 at 05:58:49PM +, Mark wrote: > > > It's a bummer that ktrace is like that on FreeBSD. It doesn't show the > > > *current* system call that the

Re: qmail-remote (cry wolf?)

On Sat, Jun 09, 2001 at 01:54:37PM -0600, Charles Cazabon wrote: > Perhaps something like a "maxlifetime" control file for qmail-remote and > qmail-smtpd? At process startup, set an alarm for X seconds -- if the ALRM is > received, abort the connection as gracefully as possible (i.e. try to sen

Re: qmail-remote (cry wolf?)

On Sat, Jun 09, 2001 at 08:11:41PM +, Mark wrote: > On Sat, Jun 09, 2001 at 01:00:46PM -0700, Jos Backus allegedly wrote: > > But FreeBSD does have a (procfs-based) truss. > > Right. But it suffers from the same problem that ktrace does in that > it starts with the next system call, not the c

Re: qmail-remote (cry wolf?)

I wanted to let the list know something about this topic. Sorry if this has been covered, but I just started following the list again because of I'm having this same problem. I'm running qmail on Redhat 6.x with a 2.2.12-20smp kernel. It has been running for well over a year (I don't remember t

Re: qmail-remote (cry wolf?)

"Dave Sill" <[EMAIL PROTECTED]> writes: > Three of the four are running Red Hat 6.2. That could simply be > because 75% of qmail systems are running RH 6.2, though. :-) I see this problem occasionally, with mail being sent from a Solaris 2.6 system. It frequently happens for mail to one particula

Re: qmail-remote (cry wolf?)

I came across the following, which *might* explain some of these deadlocking problems: [Summary: Some systems leave the fd_sets alone when select times out.] If I read this right, timeoutconn/read/write (and anything else that uses selec

Re: qmail-remote (cry wolf?)

Mark Jefferys <[EMAIL PROTECTED]> writes: > [Summary: Some systems leave the fd_sets alone when select times out.] > Even if an OS doesn't do this intentionally, it's quite easy to see > someone forgetting to clear the fd_sets on a timeout by accident, so > some defensive coding against the probl

Re: qmail-remote (cry wolf?)

Hi, > > [Summary: Some systems leave the fd_sets alone when select times out.] > I think it isn't relevant. qmail-remote doesn't seem to use select, It does. timeoutread.c: int timeoutread(t,fd,buf,len) int t; int fd; char *buf; int len; { fd_set rfds; struct timeval tv; tv.tv_sec = t;

Re: qmail-remote (cry wolf?)

On Mon, Jun 18, 2001 at 11:05:34PM +0200, Claudio Nieder allegedly wrote: > On Solaris the above code would work without flaws. > > > whereas SunOS 4.1.4 (my usual 'old bsd system' benchmark) says: > > descriptor sets. 0 indicates that the time limit referred > > to by timeout ex

Re: qmail-remote (cry wolf?)

On Sun, Jun 17, 2001 at 08:56:13PM +0100, James R Grinter wrote: % I think it isn't relevant. qmail-remote doesn't seem to use select, % or at least it's nowhere in the path where my qmail-remote wedges. Go look at timeoutread(), which *is* in your path. The select is in the line right before w

RE: qmail-remote (cry wolf?)

--Original Message- ** From: Mark Jefferys [mailto:[EMAIL PROTECTED]] ** Sent: Monday, June 18, 2001 9:27 PM ** To: James R Grinter ** Cc: [EMAIL PROTECTED] ** Subject: Re: qmail-remote (cry wolf?) ** ** ** On Sun, Jun 17, 2001 at 08:56:13PM +0100, James R Grinter wrote: ** ** % I think it isn't

Re: qmail-remote (cry wolf?)

On Mon, Jun 18, 2001 at 11:20:36PM -0400, Troy Settle wrote: % How would I need to go about building a dubug version of qmail-remote? I set conf-cc and conf-ld to 'gcc -g', edited timeoutread.c slightly to save the return value of the select in a variable, then built qmail-remote and put it in p

Re: qmail-remote (cry wolf?)

On Tue 19 Jun, 2001, Mark Jefferys <[EMAIL PROTECTED]> wrote: >On Sun, Jun 17, 2001 at 08:56:13PM +0100, James R Grinter wrote: >Go look at timeoutread(), which *is* in your path. The select is in >the line right before where you wedge. sorry, yes. You're right. >It doesn't. (Don't know about