Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue

Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue

[Jeff V. Merkey]

Hey guys,

We got to the bottom of the sendmail problem.  The line:

 -O QueueLA=20 

and

 -O RefuseLA=18

Need to be cranked up in sendmail.cf to something high since the
background VM on a very busy Linux box seems to exceed this which causes
large emails to get stuck in the /var/spool/mqueue directory for long
periods of time.  Since vger is getting hammered with FTP all the time,
and is rarely idle.  This also explains what Richard was seeing with VM
thrashing in a box with low memory.  

The problem of dropping connections on 2.4 was related to the O RefuseLA
settings.  The defaults  in the RedHat, Suse, and OpenLinux RPMs are
clearly set too low for modern Linux kernels.  You may want them cranked
up to 100 or something if you want sendmail to always work.  

Jeff

"Jeff V. Merkey" wrote:
> 
> Claus,
> 
> This is a bug.  emails should not get stuck in the mail queue because
> your load averaging routine doesn't work right.  If this is so, then why
> do some emails (small ones) get through and big ones do not,
> irreguardless of delivery order.  If it were a loading problem one would
> think emails would still get processed in the order they arrived, not
> some arbitrary "order from hell" which is what was happening.  This is
> severely broken IMHO and you need to fix it.
> 
> Jeff
> 
> Claus Assmann wrote:
> >
> > All of these entries have an 'X':
> >
> > >               Mail Queue (11 requests)
> > > --Q-ID-- --Size-- -Priority- ---Q-Time--- -----------Sender/Recipient-----------
> > > FAA15716X   31418     200564 Nov  9 05:01 <linux-kernel-owner@vger.kernel.org>
> > >           7BIT
> > >                                         <linux-archive@timpanogas.org>
> > >                                         <jmerkey@timpanogas.org>
> > > FAA20318X   32693     201751 Nov 10 05:29 <linux-kernel-owner@vger.kernel.org>
> > >           7BIT
> > >                                         <linux-archive@timpanogas.org>
> > >                                         <jmerkey@timpanogas.org>
> > > SAA01998X   34484     203865 Nov  6 18:20 <linux-kernel-owner@vger.kernel.org>
> > >           7BIT
> > >                                         <linux-archive@timpanogas.org>
> > >                                         <jmerkey@timpanogas.org>
> > > QAA01341X   65091     204150 Nov  6 16:50 <linux-kernel-owner@vger.kernel.org>
> > >           7BIT
> > >                                         <mharris@opensourceadvocate.org>
> > > SAA13390X   41368     210478 Nov  8 18:03 <linux-kernel-owner@vger.kernel.org>
> > >           7BIT
> > >                                         <linux-archive@timpanogas.org>
> > >                                         <jmerkey@timpanogas.org>
> > > LAA03425X  158115     218595 Nov  6 11:27 <jmerkey@timpanogas.org>
> > >                                         <Mark.Coe@rrd.com>
> > >                                         <jmerkey@timpanogas.com>
> > > QAA01343X   65091     234150 Nov  6 16:50 <linux-kernel-owner@vger.kernel.org>
> > >           7BIT
> > >                                         <linux-archive@timpanogas.org>
> > >                                         <jmerkey@timpanogas.org>
> > > KAA21225X  205041     235799 Nov 10 10:26 <paperboy@g2news.com>
> > >       8BITMIME
> > >                                         <jmerkey@timpanogas.com>
> > > FAA20229X    1457     272283+Nov 10 05:01 <mharris@opensourceadvocate.org>
> > >                  (Warning: could not send message for past 1 hour)
> > >                                         <andre@linux-ide.org>
> > > QAA06681X  242511     272929 Nov  7 16:18 <jmerkey@timpanogas.org>
> > >       8BITMIME
> > >                                         <andre@timpanogas.org>
> > > PAA12261X  576306     606701 Nov  8 15:06 <langus@timpanogas.com>
> > >                                         <jmerkey@timpanogas.com>
> >
> > That is, the load on your machine is too high.
> >   3:27pm  up 29 min,  2 users,  load average: 10.00, 9.97, 8.50
> >
> > It seems as if this is broken, top shows 2 running processes
> > and 67 sleeping.
> >
> > If you run the queue with -O QueueLA=20 the entries are processed.
> > So you have to change your configuration to deal with the "high"
> > load, which I did right now by editing your .cf file.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue

[Neil W Rickert]

"Jeff V. Merkey" <jmerkey@timpanogas.org> wrote:

>The problem of dropping connections on 2.4 was related to the O RefuseLA
>settings.  The defaults  in the RedHat, Suse, and OpenLinux RPMs are
>clearly set too low for modern Linux kernels.  You may want them cranked
>up to 100 or something if you want sendmail to always work.  

If a modern Linux kernel requires high load average defaults, I will
stop using Linux.

 -NWR

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue

[Jeff V. Merkey]

Then perhaps qmail's time has finally come .... If sendmail cannot run
on a machine with minimal background loading from a dozen or so FTP
clients downloading files, it's clearly sick.  BTW.  I have another box
running qmail, and it doesn't have these problems.

Jeff

Neil W Rickert wrote:
> 
> "Jeff V. Merkey" <jmerkey@timpanogas.org> wrote:
> 
> >The problem of dropping connections on 2.4 was related to the O RefuseLA
> >settings.  The defaults  in the RedHat, Suse, and OpenLinux RPMs are
> >clearly set too low for modern Linux kernels.  You may want them cranked
> >up to 100 or something if you want sendmail to always work.
> 
> If a modern Linux kernel requires high load average defaults, I will
> stop using Linux.
> 
>  -NWR
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue

[Jeff V. Merkey]

David Lang wrote:
> 
> how many CPUs in these high loadave boxes? unless you have a very
> impressive machine (8+SMP) the defaults should be plenty high.
> 
> also I thought the QueueLA default was 8 and the RefuseLA was 12 or have
> they been bumped up since I last examined them (8.8/8.9 timeframes)

I think this may be related to VM activity.  I looked at /proc/meminfo
and the sendmail sickness seems directly related to heavy VM activity in
the box.  This may be one for Rik/Linus.  I'm just trying to get
Ute-NWFS out the door and want stuff to work.  

:-)

Jeff

> 
> David Lang
> 
> On Fri, 10 Nov 2000, Jeff V. Merkey wrote:
> 
> > Date: Fri, 10 Nov 2000 14:52:01 -0700
> > From: Jeff V. Merkey <jmerkey@timpanogas.org>
> > To: sendmail-bugs@sendmail.org, linux-kernel@vger.kernel.org
> > Subject: Re: sendmail fails to deliver mail with attachments in
> >     /var/spool/mqueue
> >
> >
> >
> > Hey guys,
> >
> > We got to the bottom of the sendmail problem.  The line:
> >
> >  -O QueueLA=20
> >
> > and
> >
> >  -O RefuseLA=18
> >
> > Need to be cranked up in sendmail.cf to something high since the
> > background VM on a very busy Linux box seems to exceed this which causes
> > large emails to get stuck in the /var/spool/mqueue directory for long
> > periods of time.  Since vger is getting hammered with FTP all the time,
> > and is rarely idle.  This also explains what Richard was seeing with VM
> > thrashing in a box with low memory.
> >
> > The problem of dropping connections on 2.4 was related to the O RefuseLA
> > settings.  The defaults  in the RedHat, Suse, and OpenLinux RPMs are
> > clearly set too low for modern Linux kernels.  You may want them cranked
> > up to 100 or something if you want sendmail to always work.
> >
> > Jeff
> >
> > "Jeff V. Merkey" wrote:
> > >
> > > Claus,
> > >
> > > This is a bug.  emails should not get stuck in the mail queue because
> > > your load averaging routine doesn't work right.  If this is so, then why
> > > do some emails (small ones) get through and big ones do not,
> > > irreguardless of delivery order.  If it were a loading problem one would
> > > think emails would still get processed in the order they arrived, not
> > > some arbitrary "order from hell" which is what was happening.  This is
> > > severely broken IMHO and you need to fix it.
> > >
> > > Jeff
> > >
> > > Claus Assmann wrote:
> > > >
> > > > All of these entries have an 'X':
> > > >
> > > > >               Mail Queue (11 requests)
> > > > > --Q-ID-- --Size-- -Priority- ---Q-Time--- -----------Sender/Recipient-----------
> > > > > FAA15716X   31418     200564 Nov  9 05:01 <linux-kernel-owner@vger.kernel.org>
> > > > >           7BIT
> > > > >                                         <linux-archive@timpanogas.org>
> > > > >                                         <jmerkey@timpanogas.org>
> > > > > FAA20318X   32693     201751 Nov 10 05:29 <linux-kernel-owner@vger.kernel.org>
> > > > >           7BIT
> > > > >                                         <linux-archive@timpanogas.org>
> > > > >                                         <jmerkey@timpanogas.org>
> > > > > SAA01998X   34484     203865 Nov  6 18:20 <linux-kernel-owner@vger.kernel.org>
> > > > >           7BIT
> > > > >                                         <linux-archive@timpanogas.org>
> > > > >                                         <jmerkey@timpanogas.org>
> > > > > QAA01341X   65091     204150 Nov  6 16:50 <linux-kernel-owner@vger.kernel.org>
> > > > >           7BIT
> > > > >                                         <mharris@opensourceadvocate.org>
> > > > > SAA13390X   41368     210478 Nov  8 18:03 <linux-kernel-owner@vger.kernel.org>
> > > > >           7BIT
> > > > >                                         <linux-archive@timpanogas.org>
> > > > >                                         <jmerkey@timpanogas.org>
> > > > > LAA03425X  158115     218595 Nov  6 11:27 <jmerkey@timpanogas.org>
> > > > >                                         <Mark.Coe@rrd.com>
> > > > >                                         <jmerkey@timpanogas.com>
> > > > > QAA01343X   65091     234150 Nov  6 16:50 <linux-kernel-owner@vger.kernel.org>
> > > > >           7BIT
> > > > >                                         <linux-archive@timpanogas.org>
> > > > >                                         <jmerkey@timpanogas.org>
> > > > > KAA21225X  205041     235799 Nov 10 10:26 <paperboy@g2news.com>
> > > > >       8BITMIME
> > > > >                                         <jmerkey@timpanogas.com>
> > > > > FAA20229X    1457     272283+Nov 10 05:01 <mharris@opensourceadvocate.org>
> > > > >                  (Warning: could not send message for past 1 hour)
> > > > >                                         <andre@linux-ide.org>
> > > > > QAA06681X  242511     272929 Nov  7 16:18 <jmerkey@timpanogas.org>
> > > > >       8BITMIME
> > > > >                                         <andre@timpanogas.org>
> > > > > PAA12261X  576306     606701 Nov  8 15:06 <langus@timpanogas.com>
> > > > >                                         <jmerkey@timpanogas.com>
> > > >
> > > > That is, the load on your machine is too high.
> > > >   3:27pm  up 29 min,  2 users,  load average: 10.00, 9.97, 8.50
> > > >
> > > > It seems as if this is broken, top shows 2 running processes
> > > > and 67 sleeping.
> > > >
> > > > If you run the queue with -O QueueLA=20 the entries are processed.
> > > > So you have to change your configuration to deal with the "high"
> > > > load, which I did right now by editing your .cf file.
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > Please read the FAQ at http://www.tux.org/lkml/
> >
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue

[Alexander Viro]

On Fri, 10 Nov 2000, Jeff V. Merkey wrote:

> 
> Then perhaps qmail's time has finally come .... If sendmail cannot run
> on a machine with minimal background loading from a dozen or so FTP
> clients downloading files, it's clearly sick.  BTW.  I have another box
> running qmail, and it doesn't have these problems.

If you have permanently high load average - sure, you need to bump
the limits. Always had been that way, nothing to do with the kernel.
OTOH, I really don't see WTF are FTP clients giving that kind of LA -
unless you've got really thick pipe on a box, that is. If it's a server -
WTF are they doing there at all? And if it isn't... Nice connectivity
you have there.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue

[H. Peter Anvin]

Followup to:  <26054.973893835@euclid.cs.niu.edu>
By author:    Neil W Rickert <sendmail+rickert@sendmail.org>
In newsgroup: linux.dev.kernel
>
> "Jeff V. Merkey" <jmerkey@timpanogas.org> wrote:
> 
> >The problem of dropping connections on 2.4 was related to the O RefuseLA
> >settings.  The defaults  in the RedHat, Suse, and OpenLinux RPMs are
> >clearly set too low for modern Linux kernels.  You may want them cranked
> >up to 100 or something if you want sendmail to always work.  
> 
> If a modern Linux kernel requires high load average defaults, I will
> stop using Linux.
> 

Numerically high load averages aren't inherently a bad thing.  There
isn't anything bad about a system with a loadavg of 20 if it does what
it should in the time you'd expect.  However, if your daemons start
blocking because they assume this number means badness, than that is
the problem, not the loadavg in itself.

	-hpa

-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue

[Jeff V. Merkey]

Alexander Viro wrote:
> 
> On Fri, 10 Nov 2000, Jeff V. Merkey wrote:
> 
> >
> > Then perhaps qmail's time has finally come .... If sendmail cannot run
> > on a machine with minimal background loading from a dozen or so FTP
> > clients downloading files, it's clearly sick.  BTW.  I have another box
> > running qmail, and it doesn't have these problems.
> 
> If you have permanently high load average - sure, you need to bump
> the limits. Always had been that way, nothing to do with the kernel.
> OTOH, I really don't see WTF are FTP clients giving that kind of LA -
> unless you've got really thick pipe on a box, that is. If it's a server -
> WTF are they doing there at all? And if it isn't... Nice connectivity
> you have there.

I have dual T1 lines going into the box, and I just added a 4-way ADSL
circuit as well (4 x 550K).  Claus claimed there were TCPIP timeout bugs
in Linux (which we have now disproved).  Even despite the limits being
low, a "sendmail -v -q" command should always force delivery, and this
wasn't even working right.  This box gets hammered day and night with
FTP activity.  Had to upgrade since I learned when you post a free Linux
distriution, everyone beats a path to your door.   

Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue

[Richard A Nelson]

On Fri, 10 Nov 2000, Jeff V. Merkey wrote:

> Then perhaps qmail's time has finally come .... If sendmail cannot run
> on a machine with minimal background loading from a dozen or so FTP
> clients downloading files, it's clearly sick.  BTW.  I have another box
> running qmail, and it doesn't have these problems.

I have several boxen running sendmail with fair to moderate loading -
they even occasionally don't accept mail... and thats good, as it lets
the system catch up with its current load.  As soon as things stabalize,
sendmail again accepts connections - you *do* have MX entries don't you?

I've *never* had the problem you've got with *any* of the boxes - maybe
you should rethink your setup.  I'll wager that the qmail box isn't as
heavily loaded as the one running sendmail; why not split your services?
-- 
Rick Nelson
There are two types of Linux developers - those who can spell, and
those who can't. There is a constant pitched battle between the two.
(From one of the post-1.1.54 kernel update messages posted to c.o.l.a)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue

[Claus Assmann]

On Fri, Nov 10, 2000, David Lang wrote:
> how many CPUs in these high loadave boxes? unless you have a very
> impressive machine (8+SMP) the defaults should be plenty high.
> 
> also I thought the QueueLA default was 8 and the RefuseLA was 12 or have
> they been bumped up since I last examined them (8.8/8.9 timeframes)

Those are the defaults. Jeff quoted the values from the .cf file
I edited on his machine to get the e-mails through.

> > We got to the bottom of the sendmail problem.  The line:
> > 
> >  -O QueueLA=20 
> > 
> > and
> > 
> >  -O RefuseLA=18

Why does Linux report a LA of 10 if there are only two processes
running?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue

[Jeff V. Merkey]

"H. Peter Anvin" wrote:
> 
> Followup to:  <26054.973893835@euclid.cs.niu.edu>
> By author:    Neil W Rickert <sendmail+rickert@sendmail.org>
> In newsgroup: linux.dev.kernel
> >
> > "Jeff V. Merkey" <jmerkey@timpanogas.org> wrote:
> >
> > >The problem of dropping connections on 2.4 was related to the O RefuseLA
> > >settings.  The defaults  in the RedHat, Suse, and OpenLinux RPMs are
> > >clearly set too low for modern Linux kernels.  You may want them cranked
> > >up to 100 or something if you want sendmail to always work.
> >
> > If a modern Linux kernel requires high load average defaults, I will
> > stop using Linux.
> >
> 
> Numerically high load averages aren't inherently a bad thing.  There
> isn't anything bad about a system with a loadavg of 20 if it does what
> it should in the time you'd expect.  However, if your daemons start
> blocking because they assume this number means badness, than that is
> the problem, not the loadavg in itself.

Well, here's what the sendmail folks **REAL** opinion of Linux is and
the way load average is calculated (senders name removed)

[... sendmail person ...]

 Ok, here's my blunt answer: Linux sucks.  Why does it have a load
> average of 10 if there are two processes running? Let's check the
> man page:
> 
>             and the three load averages for the system.  The load
>             averages  are  the average number of process ready to
>             run during the last 1, 5 and 15 minutes.   This  line
>             is  just  like  the  output of uptime(1).
> 
> So: Linux load average on these systems is broken.

So I guess we know where we stand with the sendmail folks.  If the US
post office delivered mail at Christmas time using a size based priority
the way sendmail does, folks would all get their Christmas presents
about mid-February unless O NumberOfPostalWorkers=20 was set high
enough.  

Jeff


> 
>         -hpa
> 
> --
> <hpa@transmeta.com> at work, <hpa@zytor.com> in private!
> "Unix gives you enough rope to shoot yourself in the foot."
> http://www.zytor.com/~hpa/puzzle.txt
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue

[Jeff V. Merkey]

Claus Assmann wrote:
> 
> On Fri, Nov 10, 2000, Jeff V. Merkey wrote:
> 
> > I have dual T1 lines going into the box, and I just added a 4-way ADSL
> > circuit as well (4 x 550K).  Claus claimed there were TCPIP timeout bugs

You said there were TCPIP timeout bugs.  I can go retrieve the email. 
If there's this type of problem, the linux folks need to know so it can
get fixed.  

Jeff

> 
> Please DON'T quote me wrong. This is getting very annoying.
> Is that your way to spread rumours and false accusations?
> 
> Unless you come up with something constructive, I'm off this
> "discussion" now.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue

[Claus Assmann]

On Fri, Nov 10, 2000, Jeff V. Merkey wrote:

> I have dual T1 lines going into the box, and I just added a 4-way ADSL
> circuit as well (4 x 550K).  Claus claimed there were TCPIP timeout bugs

Please DON'T quote me wrong. This is getting very annoying.
Is that your way to spread rumours and false accusations?

Unless you come up with something constructive, I'm off this
"discussion" now.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue

[Jeff V. Merkey]

[ ... named redacted by request ... ] wrote:
> 
> > Well, here's what the sendmail folks **REAL** opinion of Linux is and
> > the way load average is calculated (senders name removed)
> >
> > [... sendmail person ...]
> >
> >> Ok, here's my blunt answer: Linux sucks.  Why does it have a load
> >> average of 10 if there are two processes running? Let's check the
> >> man page:
> >>
> >>             and the three load averages for the system.  The load
> >>             averages  are  the average number of process ready to
> >>             run during the last 1, 5 and 15 minutes.   This  line
> >>             is  just  like  the  output of uptime(1).
> >>
> >> So: Linux load average on these systems is broken.
> 
> If that is _our_ man page, it is broken. (well, old) Otherwise,
> this is just a case of not mindlessly obeying the BSD "standard".
> 
> Linux 2.4.xx includes some blocked processes in the load average
> calculation. This is because the BSD load average calculation
> could give a load of 0.0 when the system is severely overloaded
> by IO. I think only uninterruptable processes got added in.
> 
> Maybe this isn't the best solution... there could have been
> a second load average for IO maybe.
> 
> Feel free to forward this to the sendmail people, to the BSD people
> in case they'd like to "standardize" the new calculation, or to the
> linux-kernel mailing list for discussion -- w/o my name please.

Forwarded at the request of a tier 1 Linux person after redacting their
name.

Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue

[David Lang]

how many CPUs in these high loadave boxes? unless you have a very
impressive machine (8+SMP) the defaults should be plenty high.

also I thought the QueueLA default was 8 and the RefuseLA was 12 or have
they been bumped up since I last examined them (8.8/8.9 timeframes)

David Lang

On Fri, 10 Nov 2000, Jeff V. Merkey wrote:

> Date: Fri, 10 Nov 2000 14:52:01 -0700
> From: Jeff V. Merkey <jmerkey@timpanogas.org>
> To: sendmail-bugs@sendmail.org, linux-kernel@vger.kernel.org
> Subject: Re: sendmail fails to deliver mail with attachments in
>     /var/spool/mqueue
> 
> 
> 
> Hey guys,
> 
> We got to the bottom of the sendmail problem.  The line:
> 
>  -O QueueLA=20 
> 
> and
> 
>  -O RefuseLA=18
> 
> Need to be cranked up in sendmail.cf to something high since the
> background VM on a very busy Linux box seems to exceed this which causes
> large emails to get stuck in the /var/spool/mqueue directory for long
> periods of time.  Since vger is getting hammered with FTP all the time,
> and is rarely idle.  This also explains what Richard was seeing with VM
> thrashing in a box with low memory.  
> 
> The problem of dropping connections on 2.4 was related to the O RefuseLA
> settings.  The defaults  in the RedHat, Suse, and OpenLinux RPMs are
> clearly set too low for modern Linux kernels.  You may want them cranked
> up to 100 or something if you want sendmail to always work.  
> 
> Jeff
> 
> "Jeff V. Merkey" wrote:
> > 
> > Claus,
> > 
> > This is a bug.  emails should not get stuck in the mail queue because
> > your load averaging routine doesn't work right.  If this is so, then why
> > do some emails (small ones) get through and big ones do not,
> > irreguardless of delivery order.  If it were a loading problem one would
> > think emails would still get processed in the order they arrived, not
> > some arbitrary "order from hell" which is what was happening.  This is
> > severely broken IMHO and you need to fix it.
> > 
> > Jeff
> > 
> > Claus Assmann wrote:
> > >
> > > All of these entries have an 'X':
> > >
> > > >               Mail Queue (11 requests)
> > > > --Q-ID-- --Size-- -Priority- ---Q-Time--- -----------Sender/Recipient-----------
> > > > FAA15716X   31418     200564 Nov  9 05:01 <linux-kernel-owner@vger.kernel.org>
> > > >           7BIT
> > > >                                         <linux-archive@timpanogas.org>
> > > >                                         <jmerkey@timpanogas.org>
> > > > FAA20318X   32693     201751 Nov 10 05:29 <linux-kernel-owner@vger.kernel.org>
> > > >           7BIT
> > > >                                         <linux-archive@timpanogas.org>
> > > >                                         <jmerkey@timpanogas.org>
> > > > SAA01998X   34484     203865 Nov  6 18:20 <linux-kernel-owner@vger.kernel.org>
> > > >           7BIT
> > > >                                         <linux-archive@timpanogas.org>
> > > >                                         <jmerkey@timpanogas.org>
> > > > QAA01341X   65091     204150 Nov  6 16:50 <linux-kernel-owner@vger.kernel.org>
> > > >           7BIT
> > > >                                         <mharris@opensourceadvocate.org>
> > > > SAA13390X   41368     210478 Nov  8 18:03 <linux-kernel-owner@vger.kernel.org>
> > > >           7BIT
> > > >                                         <linux-archive@timpanogas.org>
> > > >                                         <jmerkey@timpanogas.org>
> > > > LAA03425X  158115     218595 Nov  6 11:27 <jmerkey@timpanogas.org>
> > > >                                         <Mark.Coe@rrd.com>
> > > >                                         <jmerkey@timpanogas.com>
> > > > QAA01343X   65091     234150 Nov  6 16:50 <linux-kernel-owner@vger.kernel.org>
> > > >           7BIT
> > > >                                         <linux-archive@timpanogas.org>
> > > >                                         <jmerkey@timpanogas.org>
> > > > KAA21225X  205041     235799 Nov 10 10:26 <paperboy@g2news.com>
> > > >       8BITMIME
> > > >                                         <jmerkey@timpanogas.com>
> > > > FAA20229X    1457     272283+Nov 10 05:01 <mharris@opensourceadvocate.org>
> > > >                  (Warning: could not send message for past 1 hour)
> > > >                                         <andre@linux-ide.org>
> > > > QAA06681X  242511     272929 Nov  7 16:18 <jmerkey@timpanogas.org>
> > > >       8BITMIME
> > > >                                         <andre@timpanogas.org>
> > > > PAA12261X  576306     606701 Nov  8 15:06 <langus@timpanogas.com>
> > > >                                         <jmerkey@timpanogas.com>
> > >
> > > That is, the load on your machine is too high.
> > >   3:27pm  up 29 min,  2 users,  load average: 10.00, 9.97, 8.50
> > >
> > > It seems as if this is broken, top shows 2 running processes
> > > and 67 sleeping.
> > >
> > > If you run the queue with -O QueueLA=20 the entries are processed.
> > > So you have to change your configuration to deal with the "high"
> > > load, which I did right now by editing your .cf file.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> Please read the FAQ at http://www.tux.org/lkml/
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue

[H. Peter Anvin]

Followup to:  <20001110142547.F16213@sendmail.com>
By author:    Claus Assmann <sendmail+ca@sendmail.org>
In newsgroup: linux.dev.kernel
> 
> Why does Linux report a LA of 10 if there are only two processes
> running?
> 

Load Average = runnable processes (R) + processes in disk wait (D).

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue

[Davide Libenzi]

On Fri, 10 Nov 2000, Neil W Rickert wrote:
> "Jeff V. Merkey" <jmerkey@timpanogas.org> wrote:
> 
> >The problem of dropping connections on 2.4 was related to the O RefuseLA
> >settings.  The defaults  in the RedHat, Suse, and OpenLinux RPMs are
> >clearly set too low for modern Linux kernels.  You may want them cranked
> >up to 100 or something if you want sendmail to always work.  
> 
> If a modern Linux kernel requires high load average defaults, I will
> stop using Linux.

It _depends_ on what the kernel is doing.
In my Co. We've our MTA ( PIII 800 ) with LA > 40 often ...
but it's processing a sustained load of 120000 msg/hour.



- Davide
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue

[Ralf Baechle]

On Fri, Nov 10, 2000 at 02:18:20PM -0800, H. Peter Anvin wrote:

> Numerically high load averages aren't inherently a bad thing.  There
> isn't anything bad about a system with a loadavg of 20 if it does what
> it should in the time you'd expect.  However, if your daemons start
> blocking because they assume this number means badness, than that is
> the problem, not the loadavg in itself.

The problem seems to me that the load figure doesn't express what most
people seem to expect it to - CPU load.

  Ralf
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue

[H. Peter Anvin]

Ralf Baechle wrote:
> 
> On Fri, Nov 10, 2000 at 02:18:20PM -0800, H. Peter Anvin wrote:
> 
> > Numerically high load averages aren't inherently a bad thing.  There
> > isn't anything bad about a system with a loadavg of 20 if it does what
> > it should in the time you'd expect.  However, if your daemons start
> > blocking because they assume this number means badness, than that is
> > the problem, not the loadavg in itself.
> 
> The problem seems to me that the load figure doesn't express what most
> people seem to expect it to - CPU load.
> 

Actually, what most people expect it to represent is schedulability of
new tasks.  The problem is more one of:

a) Expecting a fixed relationship between the specific number and the
behaviour of the machine;
b) The long time constants.

On an 8-way machine a load average of 16 is not particularly high, even
if you only count runnable processes, for example.

	-hpa

-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue

[Ralf Baechle]

Jeff,

On Fri, Nov 10, 2000 at 03:29:20PM -0700, Jeff V. Merkey wrote:

> Well, here's what the sendmail folks **REAL** opinion of Linux is and
> the way load average is calculated (senders name removed)
> 
> [... sendmail person ...]
> 
>  Ok, here's my blunt answer: Linux sucks.  Why does it have a load
> > average of 10 if there are two processes running? Let's check the
> > man page:
> > 
> >             and the three load averages for the system.  The load
> >             averages  are  the average number of process ready to
> >             run during the last 1, 5 and 15 minutes.   This  line
> >             is  just  like  the  output of uptime(1).
> > 
> > So: Linux load average on these systems is broken.

Or the documentation is b0rken?  This is how the load figure is actually
calculated:

/*
 * Nr of active tasks - counted in fixed-point numbers
 */
static unsigned long count_active_tasks(void)
{
        struct task_struct *p;
        unsigned long nr = 0;

        read_lock(&tasklist_lock);
        for_each_task(p) {
                if ((p->state == TASK_RUNNING ||
                     (p->state & TASK_UNINTERRUPTIBLE)))
                        nr += FIXED_1;
        }
        read_unlock(&tasklist_lock);
        return nr;
}

  Ralf
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue

[H. Peter Anvin]

Ralf Baechle wrote:
> 
> Jeff,
> 
> On Fri, Nov 10, 2000 at 03:29:20PM -0700, Jeff V. Merkey wrote:
> 
> > Well, here's what the sendmail folks **REAL** opinion of Linux is and
> > the way load average is calculated (senders name removed)
> >
> > [... sendmail person ...]
> >
> >  Ok, here's my blunt answer: Linux sucks.  Why does it have a load
> > > average of 10 if there are two processes running? Let's check the
> > > man page:
> > >
> > >             and the three load averages for the system.  The load
> > >             averages  are  the average number of process ready to
> > >             run during the last 1, 5 and 15 minutes.   This  line
> > >             is  just  like  the  output of uptime(1).
> > >
> > > So: Linux load average on these systems is broken.
> 
> Or the documentation is b0rken?  This is how the load figure is actually
> calculated:
> 
> /*
>  * Nr of active tasks - counted in fixed-point numbers
>  */
> static unsigned long count_active_tasks(void)
> {
>         struct task_struct *p;
>         unsigned long nr = 0;
> 
>         read_lock(&tasklist_lock);
>         for_each_task(p) {
>                 if ((p->state == TASK_RUNNING ||
>                      (p->state & TASK_UNINTERRUPTIBLE)))
>                         nr += FIXED_1;
>         }
>         read_unlock(&tasklist_lock);
>         return nr;
> }
> 

Yes, the documentation is broken.  Linus did in fact implement this
change because it made most daemons behave significantly better.  This
ought to include sendmail; it's just that on modern systems the numbers
get a little too high for it.

	-hpa

-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue

[Mohammad A. Haque]

I have this exact argument at work every so often. People coming in from
an NT environment have difficulty understanding what it is/means and
that it's not neccessarily bad when load gets above 1, etc, etc, etc.

Ralf Baechle wrote:
> 
> On Fri, Nov 10, 2000 at 02:18:20PM -0800, H. Peter Anvin wrote:
> 
> > Numerically high load averages aren't inherently a bad thing.  There
> > isn't anything bad about a system with a loadavg of 20 if it does what
> > it should in the time you'd expect.  However, if your daemons start
> > blocking because they assume this number means badness, than that is
> > the problem, not the loadavg in itself.
> 
> The problem seems to me that the load figure doesn't express what most
> people seem to expect it to - CPU load.
> 
>   Ralf

-- 

=====================================================================
Mohammad A. Haque                              http://www.haque.net/ 
                                               mhaque@haque.net

  "Alcohol and calculus don't mix.             Project Lead
   Don't drink and derive." --Unknown          http://wm.themes.org/
                                               batmanppc@themes.org
=====================================================================
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue

[Jeff V. Merkey]

On Fri, Nov 10, 2000 at 05:46:29PM -0800, H. Peter Anvin wrote:
> Ralf Baechle wrote:
> > 
> > Jeff,
> > 
> > On Fri, Nov 10, 2000 at 03:29:20PM -0700, Jeff V. Merkey wrote:
> > 
> > > Well, here's what the sendmail folks **REAL** opinion of Linux is and
> > > the way load average is calculated (senders name removed)
> > >
> > > [... sendmail person ...]
> > >
> > >  Ok, here's my blunt answer: Linux sucks.  Why does it have a load
> > > > average of 10 if there are two processes running? Let's check the
> > > > man page:
> > > >
> > > >             and the three load averages for the system.  The load
> > > >             averages  are  the average number of process ready to
> > > >             run during the last 1, 5 and 15 minutes.   This  line
> > > >             is  just  like  the  output of uptime(1).
> > > >
> > > > So: Linux load average on these systems is broken.
> > 
> > Or the documentation is b0rken?  This is how the load figure is actually
> > calculated:
> > 
> > /*
> >  * Nr of active tasks - counted in fixed-point numbers
> >  */
> > static unsigned long count_active_tasks(void)
> > {
> >         struct task_struct *p;
> >         unsigned long nr = 0;
> > 
> >         read_lock(&tasklist_lock);
> >         for_each_task(p) {
> >                 if ((p->state == TASK_RUNNING ||
> >                      (p->state & TASK_UNINTERRUPTIBLE)))
> >                         nr += FIXED_1;
> >         }
> >         read_unlock(&tasklist_lock);
> >         return nr;
> > }
> > 
> 
> Yes, the documentation is broken.  Linus did in fact implement this
> change because it made most daemons behave significantly better.  This
> ought to include sendmail; it's just that on modern systems the numbers
> get a little too high for it.


So everyone should up their defaults for most commercial Linux versions.  

Jeff

> 
> 	-hpa
> 
> -- 
> <hpa@transmeta.com> at work, <hpa@zytor.com> in private!
> "Unix gives you enough rope to shoot yourself in the foot."
> http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue

[Rogier Wolff]

H. Peter Anvin wrote:
> Followup to:  <20001110142547.F16213@sendmail.com>
> By author:    Claus Assmann <sendmail+ca@sendmail.org>
> In newsgroup: linux.dev.kernel
> > 
> > Why does Linux report a LA of 10 if there are only two processes
> > running?
> > 
> 
> Load Average = runnable processes (R) + processes in disk wait (D).

Keep in mind that on some operating systems, sometimes processes
become STUCK in "short disk wait". That may mean that if you just
discard those processes (they won't do any useful work until you
reboot the system), you will see the load average one point higher
than what should be expected. 

This is almost always a bug somewhere. 

So, if you're not actually loading the machine with 12 processes doing
disk IO, and still seeing a load of 12, chances are that there are
processes stuck in the (D) state. That's a bug. Report the bug. 

			Roger. 

-- 
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
*       Common sense is the collection of                                *
******  prejudices acquired by age eighteen.   -- Albert Einstein ********
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue

[Andrea Arcangeli]

On Fri, Nov 10, 2000 at 05:46:29PM -0800, H. Peter Anvin wrote:
> Yes, the documentation is broken.  Linus did in fact implement this

Well, also the implementation could be improved IMHO, think when we have one
houndred of tasks sleeping in uninterruptible mode because the nfs server is
down for maintenance. They're no loading the machine at all for half an hour
even while the load is 100. For sure the fix is not to account only runnable
tasks though, since when the machine trashes into swap all tasks blocks and
they almost never runs but in such a case we must report that all tasks are
trying to make progress and that they're effectively loading the machine even
if they sleeps in uninterruptible mode all the time. I'd prefer a generic
approch but also a magic for some case like nfs server down could take care of
that.

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue

[Henning P. Schmiedehausen]

jmerkey@timpanogas.org (Jeff V. Merkey) writes:


>We got to the bottom of the sendmail problem.  The line:

> -O QueueLA=20 

>and

> -O RefuseLA=18

>Need to be cranked up in sendmail.cf to something high since the
>background VM on a very busy Linux box seems to exceed this which causes
>large emails to get stuck in the /var/spool/mqueue directory for long
>periods of time.  Since vger is getting hammered with FTP all the time,
>and is rarely idle.  This also explains what Richard was seeing with VM
>thrashing in a box with low memory.  

So what? This is written in the documentation of the program? You do read
documentation, do you?

>The problem of dropping connections on 2.4 was related to the O RefuseLA
>settings.  The defaults  in the RedHat, Suse, and OpenLinux RPMs are
>clearly set too low for modern Linux kernels.  You may want them cranked
>up to 100 or something if you want sendmail to always work.  

These settings are for single user / small user numbers boxes.

If you're using an out of the vendor box distribution configuration
for a high traffic server, you're nuts. Or ignorant. Or dumb. Or your
consultant is an idiot.

	Regards
		Henning


-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue

[Henning P. Schmiedehausen]

cowboy@vnet.ibm.com (Richard A Nelson) writes:

>I have several boxen running sendmail with fair to moderate loading -
>they even occasionally don't accept mail... and thats good, as it lets
>the system catch up with its current load.  As soon as things stabalize,
>sendmail again accepts connections - you *do* have MX entries don't you?

% dig timpanogas.com mx
[...]
timpanogas.com.         1D IN MX        10 mail.timpanogas.com.


No. He _is_ clueless with a big mouth as the regular readers of LKM
already know.

"and it's all either the fault of other people or the kernel". 

	Regards
		Henning




-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue

[Jeff V. Merkey]

On Sat, Nov 11, 2000 at 12:54:20PM +0100, Andrea Arcangeli wrote:
> On Fri, Nov 10, 2000 at 05:46:29PM -0800, H. Peter Anvin wrote:
> > Yes, the documentation is broken.  Linus did in fact implement this
> 
> Well, also the implementation could be improved IMHO, think when we have one
> houndred of tasks sleeping in uninterruptible mode because the nfs server is
> down for maintenance. They're no loading the machine at all for half an hour
> even while the load is 100. For sure the fix is not to account only runnable
> tasks though, since when the machine trashes into swap all tasks blocks and
> they almost never runs but in such a case we must report that all tasks are
> trying to make progress and that they're effectively loading the machine even
> if they sleeps in uninterruptible mode all the time. I'd prefer a generic
> approch but also a magic for some case like nfs server down could take care of
> that.

I've actualy seen this with a bunch of NFS clients idle, and sendmail stops
delivering email until the load average drops.  What's of more concern is
the intense VM implementation Rik has done -- it's a great piece of work,
but it appears when heavy swapping is going on, sendmail also stops 
delivering email as well.  

8)

Jeff

> 
> Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue

[Jeff V. Merkey]

On Sat, Nov 11, 2000 at 01:40:42PM +0000, Henning P. Schmiedehausen wrote:
> jmerkey@timpanogas.org (Jeff V. Merkey) writes:
> 
> 
> >We got to the bottom of the sendmail problem.  The line:
> 
> > -O QueueLA=20 
> 
> >and
> 
> > -O RefuseLA=18
> 
> >Need to be cranked up in sendmail.cf to something high since the
> >background VM on a very busy Linux box seems to exceed this which causes
> >large emails to get stuck in the /var/spool/mqueue directory for long
> >periods of time.  Since vger is getting hammered with FTP all the time,
> >and is rarely idle.  This also explains what Richard was seeing with VM
> >thrashing in a box with low memory.  
> 
> So what? This is written in the documentation of the program? You do read
> documentation, do you?
> 
> >The problem of dropping connections on 2.4 was related to the O RefuseLA
> >settings.  The defaults  in the RedHat, Suse, and OpenLinux RPMs are
> >clearly set too low for modern Linux kernels.  You may want them cranked
> >up to 100 or something if you want sendmail to always work.  
> 
> These settings are for single user / small user numbers boxes.
> 
> If you're using an out of the vendor box distribution configuration
> for a high traffic server, you're nuts. Or ignorant. Or dumb. Or your
> consultant is an idiot.
> 
> 	Regards
> 		Henning


I guess all customers are idiots then, since about 100+ people who were
using our release downloaded it, and had these problems with sendmail.  This
disconnect of yours is about what I would expect from someone in a University.
Some of us don't have the luxury of being able to pontificate in a Univ
environment -- we have to make a living from Linux -- and provide payroll
for the people on this list who actually do the core work on Linux.  

If there were not a commercialization effort around Linux, it would still
be unknown, like TMOK or a lot of other kernels sitting in universities
somewhere not being deployed.  It's the commercialization effort that made
Linux a household word.  NT and NetWare servers don't stop forwarding 
emails when the load average gets too high -- they just work out of the
box, and hopefully, no so will Linux (our distribution does now since 
this problem in fixed).

Now we know that sendmail has problems on Linux based on the this load
average interpretation, which we would not have known if someone had 
not raised the issue.  

Jeff

  

> 
> 
> -- 
> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
> INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de
> 
> Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
> D-91054 Buckenhof     Fax.: 09131 / 50654-20   
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue

[Henning P. Schmiedehausen]

jmerkey@vger.timpanogas.org (Jeff V. Merkey) writes:

>I guess all customers are idiots then, since about 100+ people who were
>using our release downloaded it, and had these problems with sendmail.  This
>disconnect of yours is about what I would expect from someone in a University.
>Some of us don't have the luxury of being able to pontificate in a Univ
>environment -- we have to make a living from Linux -- and provide payroll
>for the people on this list who actually do the core work on Linux.  

I earn a living with building and deploying Internet system on a
variety of (Unix-based) platforms. Each one has its quirks and to
build successful servers, you have to know about them. I never ever
deployed a sendmail.cf as it came from the vendor or the source
package. I adjust these config files to the customers' need.

[...]

>somewhere not being deployed.  It's the commercialization effort that made
>Linux a household word.  NT and NetWare servers don't stop forwarding 

THERE IS NO SUCH EFFORT. This list is not your general-purpose Linux
support list.

If you need support for a distribution, get it from the vendor. If you
make a distribution, that deploys a software, give this support or buy
it from people who _know_ and sell it to your customers.

But this list is not for your "I don't have a clue" efforts. Deploying
a distribution is major grunt work that most customers will never see.

I e.g. deploy a highly customized version of RedHat on the servers
that I build. Most of my customers ask a second and a third time why I
don't simply deploy the distribution out of the box like all the
consultants that they had before. They stop asking when their old
boxes are cracked open or fail under load and mine doesn't. If you
deploy a general purpose distribution or OS for a very special
application, then you simply use the wrong tool.

>emails when the load average gets too high -- they just work out of the
>box, and hopefully, no so will Linux (our distribution does now since 
>this problem in fixed).

Your distribution will simply have "RefuseLA" and "QueueLA" higher
than the sendmail defaults. This is not the solution to your problem
but moves it simply to a different point.

You simply don't understand, that a cluster mail system that handles
20,000,000 mailboxes and 200,000,000 mails per day must be configured
different than the mail system on a high traffic web server, that
simply sends out two mails per day from the logfile rotation. Both
machines may have a load average way beyond a desktop system that
peaks at 0.05 on normal usage.

>Now we know that sendmail has problems on Linux based on the this load
>average interpretation, which we would not have known if someone had 
>not raised the issue.  

Linux has no problem. Some sites that run Linux have a problem because
they're misconfigured.

And if you ship a distribution but want to load off the support for
this distribution on Linux-Kernel, you're definitely in for a
surprise. TANSTAAFL, you know.

	Regards
		Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue

[J Sloan]

"Jeff V. Merkey" wrote:

> NT and NetWare servers don't stop forwarding
> emails when the load average gets too high -- they just work out of the
> box, and hopefully, no so will Linux (our distribution does now since
> this problem in fixed).

Don't get me started on nt - saying it "just works" is a sign of
genuine naivete - You could say nt "usually works, except for
when it's down".  Your sendmail issue with Linux was merely a
tunable parameter, while the nt problems go much deeper, and
nt often requires regular reboots in order to carry on.

> Now we know that sendmail has problems on Linux based on the this load
> average interpretation, which we would not have known if someone had
> not raised the issue.

It is good that you raised the issue -

Cheers,

jjs



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue

[Jesse Pollard]

On Sat, 11 Nov 2000, Jeff V. Merkey wrote:
>On Sat, Nov 11, 2000 at 01:40:42PM +0000, Henning P. Schmiedehausen wrote:
>> jmerkey@timpanogas.org (Jeff V. Merkey) writes:
>> 
>> 
>> >We got to the bottom of the sendmail problem.  The line:
>> 
>> > -O QueueLA=20 
>> 
>> >and
>> 
>> > -O RefuseLA=18
>> 
>> >Need to be cranked up in sendmail.cf to something high since the
>> >background VM on a very busy Linux box seems to exceed this which causes
>> >large emails to get stuck in the /var/spool/mqueue directory for long
>> >periods of time.  Since vger is getting hammered with FTP all the time,
>> >and is rarely idle.  This also explains what Richard was seeing with VM
>> >thrashing in a box with low memory.  
>> 
>> So what? This is written in the documentation of the program? You do read
>> documentation, do you?
>> 
>> >The problem of dropping connections on 2.4 was related to the O RefuseLA
>> >settings.  The defaults  in the RedHat, Suse, and OpenLinux RPMs are
>> >clearly set too low for modern Linux kernels.  You may want them cranked
>> >up to 100 or something if you want sendmail to always work.  
>> 
>> These settings are for single user / small user numbers boxes.
>> 
>> If you're using an out of the vendor box distribution configuration
>> for a high traffic server, you're nuts. Or ignorant. Or dumb. Or your
>> consultant is an idiot.
>> 
>> 	Regards
>> 		Henning
>
>
>I guess all customers are idiots then, since about 100+ people who were
>using our release downloaded it, and had these problems with sendmail.  This
>disconnect of yours is about what I would expect from someone in a University.
>Some of us don't have the luxury of being able to pontificate in a Univ
>environment -- we have to make a living from Linux -- and provide payroll
>for the people on this list who actually do the core work on Linux.  
>
>If there were not a commercialization effort around Linux, it would still
>be unknown, like TMOK or a lot of other kernels sitting in universities
>somewhere not being deployed.  It's the commercialization effort that made
>Linux a household word.  NT and NetWare servers don't stop forwarding 
>emails when the load average gets too high -- they just work out of the
>box, and hopefully, no so will Linux (our distribution does now since 
>this problem in fixed).
>
>Now we know that sendmail has problems on Linux based on the this load
>average interpretation, which we would not have known if someone had 
>not raised the issue.  

This is not a problem with sendmail on Linux. The same thing will happen
on ANY uni-processor system (multi-processor too, but not as severe).

I run sendmail on an SGI Indy (yes, that no-longer-manufactured thing) and
it is necessary to set the load average on it to 75 or so. As high as 150
is not unreasonable either. This system handles 10's of thousands of mail
messages per day.

This is only a matter of tuning sendmail to do what you want, when you want.
It is also reasonably well documented in the sendmail distribution. You do
have to monitor the system to determine what "high" really is.

In the case of the NT servers, I have seen them choke (and crash) since they
DON'T seem to throttle very well.

BTW, After I read the sendmail documentation, and observed the system for
a while, I decided to count the sendmail "loadaverage" as really being the
average number of simultaneous connections (sendmail processes/threads).
This leads to the choice of "how many do I want active, and how many do
I want to suspended, and when do I want to refuse connection". THEN I add
the number of other active processes to the proposed limits.

-- 
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@cats-chateau.net

Any opinions expressed are solely my own.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue

[Jeff V. Merkey]

On Sat, Nov 11, 2000 at 11:38:31AM -0800, J Sloan wrote:
> "Jeff V. Merkey" wrote:
> 
> It is good that you raised the issue -

THanks

Jeff

> 
> Cheers,
> 
> jjs
> 
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/