[Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

[Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

[Jeff V. Merkey]

[-- Attachment #1: Type: text/plain, Size: 895 bytes --]


The sendmail folks are claiming that the TCPIP stack in Linux is broken,
which is what they claim is causing problems on sendmail on Linux
platforms.  Before anyone says, "don't use that piece of shit sendmail,
use qmail instead", perhaps we should look at this problem and refute
these statements -- I think that sendmail is causing this problem.  The
version is sendmail 8.9.3

I can reproduce this bug on RH6.2, RH7.0, Caldera 2.2, 2.3, and 2.4,
Suse 6.X versions, and any of these distributions with the following
kernels.   

2.2.14, 2.2.16, 2.2.17, 2.2.18, 2.4.0 (all).  What happens is that
sendmail fails to forward mails with any attachments larger than 400K,
and they just sit in the /var/spool/mqueue directory for up to a week,
and eventually get delivered.

ANyone have any ideas if what the sendmail people are saying is on the
level, or is this just another sendmail bug.  

Jeff

[-- Attachment #2: Type: message/rfc822, Size: 7515 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 1538 bytes --]

Claus,

Here's the output from mailq -v and ps -ax.  As you can see, sendmail is
seriously malfunctining.  I have seen this same bug accross three
platforms with a wide variety 
of linux kernels from 2.2.14 to 2.2.18 to 2.4.0-10.  This is your bug,
and noone else's.

How do we get it fixed or is it possibly a configuration error.

Jeff

Claus Assmann wrote:
> 
> On Fri, Nov 10, 2000, Jeff V. Merkey wrote:
> >
> >
> > Claus Assmann wrote:
> > >
> > > On Fri, Nov 10, 2000, root wrote:
> > > >
> > > > I am seeimg sendmail 8.9.3 fail to deliver emails in /var/spool/mqueue
> > > > with attachements for up to a week.  Issuing the command "sendmail -v
> > > > -q" does not flush the mail queue.
> > >
> > > Is the queue item locked? What happens when you try to run it?
> >
> > How do I tell if the queue item is locked.  If you have a web browser, I
> 
> mailq -v
> look for a '*' next to the id.
> 
> > am running
> > webmin on the box and I have setup an account so you can come in and see
> > the mail queue yourself.
> >
> > enter www.timpanogas.org:10000 as your URL, then login as
> > username "sendmail" and password "sendmailbugs".   I will disable this
> 
> I don't know webmin, but most of the entries say "sending".  So
> check your sendmail processes to see what they are doing.  There
> might be some Linux TCP/IP stack bug that causes the problem (no
> proper timeout). For that you need to use trace/truss to see where
> the processes hang and how old they are.
> 
> I couldn't see any local delivery or very old entries.

[-- Attachment #2.1.2: ps.txt --]
[-- Type: text/plain, Size: 3116 bytes --]

  PID TTY      STAT   TIME COMMAND
    1 ?        S      0:06 init [3]
    2 ?        SW     0:00 [kflushd]
    3 ?        SW     0:01 [kupdate]
    4 ?        SW     0:00 [kpiod]
    5 ?        SW     0:00 [kswapd]
   95 ?        S      0:00 /sbin/modprobe -s -k nwfs
   96 ?        D      0:00 /sbin/modprobe -s -k nwfs
   97 ?        D      0:00 /sbin/modprobe -s -k nwfs
   98 ?        D      0:18 /sbin/modprobe -s -k nwfs
   99 ?        D      0:00 /sbin/modprobe -s -k nwfs
  100 ?        D      0:05 /sbin/modprobe -s -k nwfs
  101 ?        D      0:00 /sbin/modprobe -s -k nwfs
  102 ?        D      0:00 /sbin/modprobe -s -k nwfs
  103 ?        D      0:00 /sbin/modprobe -s -k nwfs
  104 ?        D      0:00 /sbin/modprobe -s -k nwfs
  105 ?        D      0:00 /sbin/modprobe -s -k nwfs
  344 ?        S      0:00 portmap
  367 ?        S      0:00 rpc.statd
  390 ?        S      0:00 /usr/sbin/automount /misc file /etc/auto.misc
  405 ?        S      0:00 /usr/sbin/apmd -p 10 -w 5 -W -s /etc/sysconfig/apm-sc
  456 ?        S      0:19 syslogd -m 0
  465 ?        S      0:00 klogd
  479 ?        S      0:00 identd -e -o
  483 ?        S      0:00 identd -e -o
  484 ?        S      0:00 identd -e -o
  485 ?        S      0:00 identd -e -o
  486 ?        S      0:00 identd -e -o
  497 ?        S      0:00 /usr/sbin/atd
  511 ?        S      0:00 crond
  529 ?        S      0:01 inetd
  543 ?        S      0:20 named -u named
  557 ?        S      0:00 lpd
  616 ?        S      0:00 gpm -t ps/2
  630 ?        S      0:00 httpd
  709 ?        S      0:00 xfs -droppriv -daemon -port -1
  750 ?        S      0:06 /usr/sbin/sshd
  755 tty2     S      0:00 /sbin/mingetty tty2
  756 tty3     S      0:00 /sbin/mingetty tty3
  757 tty4     S      0:00 /sbin/mingetty tty4
  758 tty5     S      0:00 /sbin/mingetty tty5
  759 tty6     S      0:00 /sbin/mingetty tty6
 2611 tty1     S      0:00 /sbin/mingetty tty1
16526 ?        S      0:00 httpd
16528 ?        S      0:00 httpd
18678 ?        S      0:00 httpd
18679 ?        S      0:00 httpd
18680 ?        S      0:00 httpd
18681 ?        S      0:00 httpd
18682 ?        S      0:00 httpd
18683 ?        S      0:00 httpd
19308 ?        S      0:00 httpd
19309 ?        S      0:00 httpd
19310 ?        S      0:00 httpd
20757 ?        S      0:00 httpd
20936 ?        S      0:00 httpd
20937 ?        S      0:00 httpd
20938 ?        S      0:00 httpd
20939 ?        S      0:00 httpd
20940 ?        S      0:00 httpd
20941 ?        S      0:00 httpd
22244 ?        S      0:00 sendmail: accepting connections on port 25
22331 ?        S      0:00 in.telnetd: manos.timpanogas.org                     
22332 pts/1    S      0:00 login -- jmerkey                    
22333 pts/1    S      0:00 -bash
22359 pts/1    S      0:00 su -
22360 pts/1    S      0:00 -bash
22638 ?        S      0:00 ftpd: cvx-36.flex.com: anonymous/guest@unknown.net: R
22841 ?        S      0:00 ftpd: cadmium.sge.net: anonymous/bpftp@: IDLE        
22866 ?        S      0:00 perl /usr/libexec/webmin/miniserv.pl /etc/webmin/mini
22875 pts/1    R      0:00 ps -ax

[-- Attachment #2.1.3: mailq.txt --]
[-- Type: text/plain, Size: 1679 bytes --]

		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>

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

[William F. Maton]

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

> 
> The sendmail folks are claiming that the TCPIP stack in Linux is broken,
> which is what they claim is causing problems on sendmail on Linux
> platforms.  Before anyone says, "don't use that piece of shit sendmail,
> use qmail instead", perhaps we should look at this problem and refute
> these statements -- I think that sendmail is causing this problem.  The
> version is sendmail 8.9.3

What about sendmail 8.11.1?  Is the problem there too?

> 
> I can reproduce this bug on RH6.2, RH7.0, Caldera 2.2, 2.3, and 2.4,
> Suse 6.X versions, and any of these distributions with the following
> kernels.   
> 
> 2.2.14, 2.2.16, 2.2.17, 2.2.18, 2.4.0 (all).  What happens is that
> sendmail fails to forward mails with any attachments larger than 400K,
> and they just sit in the /var/spool/mqueue directory for up to a week,
> and eventually get delivered.
> 
> ANyone have any ideas if what the sendmail people are saying is on the
> level, or is this just another sendmail bug.  
> 
> Jeff



wfms

-
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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

[Jeff V. Merkey]

"William F. Maton" wrote:
> 
> On Fri, 10 Nov 2000, Jeff V. Merkey wrote:
> 
> >
> > The sendmail folks are claiming that the TCPIP stack in Linux is broken,
> > which is what they claim is causing problems on sendmail on Linux
> > platforms.  Before anyone says, "don't use that piece of shit sendmail,
> > use qmail instead", perhaps we should look at this problem and refute
> > these statements -- I think that sendmail is causing this problem.  The
> > version is sendmail 8.9.3
> 
> What about sendmail 8.11.1?  Is the problem there too?

Yes.  Plus 8.11.1 has problems talking to older sendmails sine it uses
encryption.
> 
> >
> > I can reproduce this bug on RH6.2, RH7.0, Caldera 2.2, 2.3, and 2.4,
> > Suse 6.X versions, and any of these distributions with the following
> > kernels.
> >
> > 2.2.14, 2.2.16, 2.2.17, 2.2.18, 2.4.0 (all).  What happens is that
> > sendmail fails to forward mails with any attachments larger than 400K,
> > and they just sit in the /var/spool/mqueue directory for up to a week,
> > and eventually get delivered.
> >
> > ANyone have any ideas if what the sendmail people are saying is on the
> > level, or is this just another sendmail bug.
> >
> > Jeff
> 
> wfms
-
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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

[Horst von Brand]

"Jeff V. Merkey" <jmerkey@timpanogas.org> SAID:
> "William F. Maton" wrote:

[...]

> > What about sendmail 8.11.1?  Is the problem there too?

> Yes.  Plus 8.11.1 has problems talking to older sendmails sine it uses
> encryption.

I've been using sendmail-8.11.1 (no encryption) to talk to MTAs all over
the place, many of them so old it is scary. No problems seen at this end.
This is to be expected, BTW: They can't just go in and release an MTA which
doesn't talk to the rest ot the world, now can they.
-- 
Dr. Horst H. von Brand                       mailto:vonbrand@inf.utfsm.cl
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513
-
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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

[Jeff V. Merkey]

Horst von Brand wrote:
> 
> "Jeff V. Merkey" <jmerkey@timpanogas.org> SAID:
> > "William F. Maton" wrote:
> 
> [...]
> 
> > > What about sendmail 8.11.1?  Is the problem there too?
> 
> > Yes.  Plus 8.11.1 has problems talking to older sendmails sine it uses
> > encryption.
> 
> I've been using sendmail-8.11.1 (no encryption) to talk to MTAs all over
                                   ^^^^^^^^^^^^^^

Turn on encryption, and try sending attachements > 1MB and tell me if
you see any problems, like emails sitting in /var/spool/mqueue for a day
or two until they go out.  I can guarantee you will.

Jeff


> the place, many of them so old it is scary. No problems seen at this end.
> This is to be expected, BTW: They can't just go in and release an MTA which
> doesn't talk to the rest ot the world, now can they.
> --
> Dr. Horst H. von Brand                       mailto:vonbrand@inf.utfsm.cl
> Departamento de Informatica                     Fono: +56 32 654431
> Universidad Tecnica Federico Santa Maria              +56 32 654239
> Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513
-
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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

[Horst von Brand]

"Jeff V. Merkey" <jmerkey@timpanogas.org> said:
> Horst von Brand wrote:

[...]

> > I've been using sendmail-8.11.1 (no encryption) to talk to MTAs all over

> Turn on encryption, and try sending attachements > 1MB and tell me if
> you see any problems, like emails sitting in /var/spool/mqueue for a day
> or two until they go out.  I can guarantee you will.

No encryption use; and the maximal message size is 1Mb (for sanity's sake,
after somebody sent a PowerPoint presentation (some 3Mb), then thought that
perhaps the target didn't have PowerPoint, and sent it again with the
PowerPoint package, then noticed this might not work either, and sent it
_again_ with the full MS Office attached...  the joys of sysadminning ;-)
-- 
Dr. Horst H. von Brand                       mailto:vonbrand@inf.utfsm.cl
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513
-
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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

[Tim Walberg]

[-- Attachment #1: Type: text/plain, Size: 1036 bytes --]

On 11/10/2000 16:30 -0300, Horst von Brand wrote:
>>	"Jeff V. Merkey" <jmerkey@timpanogas.org> said:
>>	> Horst von Brand wrote:
>>	
>>	[...]
>>	
>>	> > I've been using sendmail-8.11.1 (no encryption) to talk to MTAs all over
>>	
>>	> Turn on encryption, and try sending attachements > 1MB and tell me if
>>	> you see any problems, like emails sitting in /var/spool/mqueue for a day
>>	> or two until they go out.  I can guarantee you will.
>>	
>>	No encryption use; and the maximal message size is 1Mb (for sanity's sake,
>>	after somebody sent a PowerPoint presentation (some 3Mb), then thought that
>>	perhaps the target didn't have PowerPoint, and sent it again with the
>>	PowerPoint package, then noticed this might not work either, and sent it
>>	_again_ with the full MS Office attached...  the joys of sysadminning ;-)
>>	-- 

Wow... that just might be one that's due for immortalizing
as an urban legend or what not... Definitely stupid user trick
material...


			tw


-- 
tewalberg@mediaone.net

[-- Attachment #2: Type: application/pgp-signature, Size: 175 bytes --]

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

[Dominik Kubla]

On Fri, Nov 10, 2000 at 01:46:39PM -0600, Tim Walberg wrote:
...
> Wow... that just might be one that's due for immortalizing
> as an urban legend or what not... Definitely stupid user trick
> material...

I can do better! I had a smart ass trying to backup his harddrives
using email, no less than 2Gig!

Dominik
-- 
http://petition.eurolinux.org/index_html - No Software Patents In Europe!
http://petition.lugs.ch/ (in Switzerland)
-
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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

[Henning P. Schmiedehausen]

dominik.kubla@uni-mainz.de (Dominik Kubla) writes:

>I can do better! I had a smart ass trying to backup his harddrives
>using email, no less than 2Gig!

So what? Get enough spool space in /var/spool/mqueue and a platform
with 64 bit file support and it works just fine. I have some boxes
where the users send 100+ MByte mails on a regular base. Once you beat
the procmail into submission, this simply works.

sendmail is one of the very best pieces of free multi-platform
software that is available. I really admire the people that wrote
it. Kudos to everyone that wrote on this software. All hail Eric
Allman. ;-)

It is mean, tough, hard to understand and configure but definitely
industrial strength, proven and reliable. Something you can't say of
all this sissy "free" software around today.

And once you get a hang of "left side, right side" rules, you can read
sendmail.cf like normal text. The idea of using an algorithmic concept
for a config file still shines after twenty years of development. So
much for "GUIs".

	sendmail rocks
		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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

[Igmar Palsenberg]

> Turn on encryption, and try sending attachements > 1MB and tell me if
> you see any problems, like emails sitting in /var/spool/mqueue for a day
> or two until they go out.  I can guarantee you will.

Are you talking client -> MTA encryption, or MTA -> MTA encryption ??
 
> Jeff


	Igmar

-
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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

[Jeff V. Merkey]

Igmar Palsenberg wrote:
> 
> > Turn on encryption, and try sending attachements > 1MB and tell me if
> > you see any problems, like emails sitting in /var/spool/mqueue for a day
> > or two until they go out.  I can guarantee you will.
> 
> Are you talking client -> MTA encryption, or MTA -> MTA encryption ??

slow or blocked connection problems with all configs listed above.

Jeff

> 
> > Jeff
> 
>         Igmar
> 
> -
> 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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

[Igmar Palsenberg]

> > > Turn on encryption, and try sending attachements > 1MB and tell me if
> > > you see any problems, like emails sitting in /var/spool/mqueue for a day
> > > or two until they go out.  I can guarantee you will.
> > 
> > Are you talking client -> MTA encryption, or MTA -> MTA encryption ??
> 
> slow or blocked connection problems with all configs listed above.

Ah. I'll go kick this sendmail setup, and see what it does..


> Jeff


	Igmar

-
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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

[Igmar Palsenberg]

> > Yes.  Plus 8.11.1 has problems talking to older sendmails sine it uses
> > encryption.
> 
> I've been using sendmail-8.11.1 (no encryption) to talk to MTAs all over
> the place, many of them so old it is scary. No problems seen at this end.
> This is to be expected, BTW: They can't just go in and release an MTA which
> doesn't talk to the rest ot the world, now can they.

The only things sendmails < 8.10.x all suffer from is the crappy mapper
code. This causes all kinds of weard problems (logging not complete,
undelivered mail), especially if an external problem mucks around with the
mapper files (those .db things for example).

I had no problems with 8.11.x not talking to qmail or any other MTA.



	Igmar

-
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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

[Richard A Nelson]

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

> "William F. Maton" wrote:
> >
> > What about sendmail 8.11.1?  Is the problem there too?
>
> Yes.  Plus 8.11.1 has problems talking to older sendmails sine it uses
> encryption.

Eh?!? TLS is an optional, negotiated protocol started *after* the two
sendmails are communicating.

I've not seen any problems, save a documented case with *one* third
party SMTP server (don't recall who it was).

-- 
Rick Nelson
Old MacLinus had a stack/l-i-n-u-x/and on this stack he had a trace/l-i-n-u-x
with an Oops-Oops here and an Oops-Oops there
here an Oops, there an Oops, everywhere an Oops-Oops.
	-- tjimenez@site.gmu.edu, linux.dev.kernel

-
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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

[Jeff V. Merkey]

Send me an email from it with an attachment > 1MB, and I will forward
back to you when (and if) It gets delivered before next week.

:-)

Jeff

Richard A Nelson wrote:
> 
> On Fri, 10 Nov 2000, Jeff V. Merkey wrote:
> 
> > "William F. Maton" wrote:
> > >
> > > What about sendmail 8.11.1?  Is the problem there too?
> >
> > Yes.  Plus 8.11.1 has problems talking to older sendmails sine it uses
> > encryption.
> 
> Eh?!? TLS is an optional, negotiated protocol started *after* the two
> sendmails are communicating.
> 
> I've not seen any problems, save a documented case with *one* third
> party SMTP server (don't recall who it was).
> 
> --
> Rick Nelson
> Old MacLinus had a stack/l-i-n-u-x/and on this stack he had a trace/l-i-n-u-x
> with an Oops-Oops here and an Oops-Oops there
> here an Oops, there an Oops, everywhere an Oops-Oops.
>         -- tjimenez@site.gmu.edu, linux.dev.kernel
-
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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

[William F. Maton]

On Fri, 10 Nov 2000, Richard A Nelson wrote:

> On Fri, 10 Nov 2000, Jeff V. Merkey wrote:
> 
> > "William F. Maton" wrote:
> > >
> > > What about sendmail 8.11.1?  Is the problem there too?
> >
> > Yes.  Plus 8.11.1 has problems talking to older sendmails sine it uses
> > encryption.
> 
> Eh?!? TLS is an optional, negotiated protocol started *after* the two
> sendmails are communicating.

You anticipated what I was about to type :-)
 
> I've not seen any problems, save a documented case with *one* third
> party SMTP server (don't recall who it was).

No problems here either...

> 
> -- 
> Rick Nelson
> Old MacLinus had a stack/l-i-n-u-x/and on this stack he had a trace/l-i-n-u-x
> with an Oops-Oops here and an Oops-Oops there
> here an Oops, there an Oops, everywhere an Oops-Oops.
> 	-- tjimenez@site.gmu.edu, linux.dev.kernel
> 



wfms

-
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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

[Igmar Palsenberg]

> > What about sendmail 8.11.1?  Is the problem there too?
> 
> Yes.  Plus 8.11.1 has problems talking to older sendmails sine it uses
> encryption.

Depends on how you configure it. An enabled encryption doesn't always mean
it has problems taking to other sendmails. This sendmail here has no
problems forwarding a mail > 400 Kb (I used 1.2 MB).

This is 8.11.1 with the MySQL mapper patch.

> > > ANyone have any ideas if what the sendmail people are saying is on the
> > > level, or is this just another sendmail bug.

I can't reproduce on 8.11.1

Maybe I can if someones tells me the exact procedure to reproduce it.

> > >
> > > Jeff
> > 
> > wfms


	Igmar

-
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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

[Richard B. Johnson]

On Fri, 10 Nov 2000, William F. Maton wrote:

> On Fri, 10 Nov 2000, Jeff V. Merkey wrote:
> 
> > 
> > The sendmail folks are claiming that the TCPIP stack in Linux is broken,
> > which is what they claim is causing problems on sendmail on Linux
> > platforms.  Before anyone says, "don't use that piece of shit sendmail,
> > use qmail instead", perhaps we should look at this problem and refute
> > these statements -- I think that sendmail is causing this problem.  The
> > version is sendmail 8.9.3
> 
> What about sendmail 8.11.1?  Is the problem there too?
> 

I am running sendmail-8.11-0.Beta3 on Linux 2.4.0-test9. I didn't
have any problem with it (except that the documentation sucks,
making it extremely difficult to configure). Once configured, it runs
fine. It also ran fine on Linux-2.2.17.

If something is staying in the mail-queue `mailq`, this means that
the daemon isn't running. It may have crashed. This can be caused
by somebody keeping some mailer entry in /etc/inetd.conf. Sendmail
has to run as a daemon with no other interference on port 25.
Check the configuration.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.


-
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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

[Jeff V. Merkey]

"Richard B. Johnson" wrote:
> 
> On Fri, 10 Nov 2000, William F. Maton wrote:
> 
> > On Fri, 10 Nov 2000, Jeff V. Merkey wrote:
> >
> > >
> > > The sendmail folks are claiming that the TCPIP stack in Linux is broken,
> > > which is what they claim is causing problems on sendmail on Linux
> > > platforms.  Before anyone says, "don't use that piece of shit sendmail,
> > > use qmail instead", perhaps we should look at this problem and refute
> > > these statements -- I think that sendmail is causing this problem.  The
> > > version is sendmail 8.9.3
> >
> > What about sendmail 8.11.1?  Is the problem there too?
> >
> 
> I am running sendmail-8.11-0.Beta3 on Linux 2.4.0-test9. I didn't
> have any problem with it (except that the documentation sucks,
> making it extremely difficult to configure). Once configured, it runs
> fine. It also ran fine on Linux-2.2.17.
> 
> If something is staying in the mail-queue `mailq`, this means that
> the daemon isn't running. It may have crashed. This can be caused
> by somebody keeping some mailer entry in /etc/inetd.conf. Sendmail
> has to run as a daemon with no other interference on port 25.
> Check the configuration.

I did Dick.  The config is fine.  The daemon is also fine and running. 
What's really weird is that even if I do a "sendmail -v -q" command
(which should force the queue to flush) it still doesn't. 

Jeff

> 
> Cheers,
> Dick Johnson
> 
> Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).
> 
> "Memory is like gasoline. You use it up when you are running. Of
> course you get it all back when you reboot..."; Actual explanation
> obtained from the Micro$oft help desk.
-
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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

[Henning P. Schmiedehausen]

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

>I did Dick.  The config is fine.  The daemon is also fine and running. 
>What's really weird is that even if I do a "sendmail -v -q" command
>(which should force the queue to flush) it still doesn't. 

O Timeout.ident=0s
O Timeout.initial=30s (these are the ninieties / 21st century)

Get someone that really has an idea about sendmail. 

	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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

[Jeff V. Merkey]

On Sat, Nov 11, 2000 at 01:24:18PM +0000, Henning P. Schmiedehausen wrote:
> jmerkey@timpanogas.org (Jeff V. Merkey) writes:
> 
> >I did Dick.  The config is fine.  The daemon is also fine and running. 
> >What's really weird is that even if I do a "sendmail -v -q" command
> >(which should force the queue to flush) it still doesn't. 
> 
> O Timeout.ident=0s
> O Timeout.initial=30s (these are the ninieties / 21st century)
> 
> Get someone that really has an idea about sendmail. 
> 
> 	Regards
> 		Henning

Ha ha.  It's fixed.

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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

[Richard A Nelson]

Any `real` reason you're still at 8.9.3?   Current is 8.11.1

If you send me a note of the type that fails, (to cowboy@debian.org),
it'll get received on both a 2.2.18-21/8.11.1 and 2.4.0-test10/8.11.2.Beta0
system.

-- 
Rick Nelson
'Mounten' wird für drei Dinge benutzt: 'Aufsitzen' auf Pferde, 'einklinken'
von Festplatten in Dateisysteme, und, nun, 'besteigen' beim Sex.
	-- Christa Keil

-
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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

[Jeff V. Merkey]

Richard A Nelson wrote:
> 
> Any `real` reason you're still at 8.9.3?   Current is 8.11.1
> 
> If you send me a note of the type that fails, (to cowboy@debian.org),
> it'll get received on both a 2.2.18-21/8.11.1 and 2.4.0-test10/8.11.2.Beta0

8.11.1 has problems talking to older sendmails and qmail.  I've seen
even worse problems on 8.11.1, and backreved it immediately, and the
encryption stuff has a lot of build problems on Linux. 

Jeff  


> system.
> 
> --
> Rick Nelson
> 'Mounten' wird für drei Dinge benutzt: 'Aufsitzen' auf Pferde, 'einklinken'
> von Festplatten in Dateisysteme, und, nun, 'besteigen' beim Sex.
>         -- Christa Keil
-
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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

[Richard A Nelson]

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

> 8.11.1 has problems talking to older sendmails and qmail.  I've seen
> even worse problems on 8.11.1, and backreved it immediately, and the
> encryption stuff has a lot of build problems on Linux.

Sounds like local build problems, possibly all the problems !

I can assist if you want to build 8.11.1 on Linux
-- 
Rick Nelson
Life'll kill ya                         -- Warren Zevon
Then you'll be dead                     -- Life'll kill ya

-
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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

[Jeff V. Merkey]

Since I posted this on LKML, Claus over at sendmail.org seems more
motivated to track it down.  (since it might appear on the front page of
Linux today).  I would love your assistance Richard.  
It could be a local problem since smrsh also seems to be f_cked up as
well, but I am seeing the same thing with an out of the box RH6.2.

Jeff

Richard A Nelson wrote:
> 
> On Fri, 10 Nov 2000, Jeff V. Merkey wrote:
> 
> > 8.11.1 has problems talking to older sendmails and qmail.  I've seen
> > even worse problems on 8.11.1, and backreved it immediately, and the
> > encryption stuff has a lot of build problems on Linux.
> 
> Sounds like local build problems, possibly all the problems !
> 
> I can assist if you want to build 8.11.1 on Linux
> --
> Rick Nelson
> Life'll kill ya                         -- Warren Zevon
> Then you'll be dead                     -- Life'll kill ya
> 
> -
> 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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

[Jeff V. Merkey]

Claus is sloging into the box and we will be trying to track this down. 
If it is a problem in the Linux TCPIP stack, we'll post a report later
this afternoon as to where it looks like the problem is.  

Jeff

"Jeff V. Merkey" wrote:
> 
> Since I posted this on LKML, Claus over at sendmail.org seems more
> motivated to track it down.  (since it might appear on the front page of
> Linux today).  I would love your assistance Richard.
> It could be a local problem since smrsh also seems to be f_cked up as
> well, but I am seeing the same thing with an out of the box RH6.2.
> 
> Jeff
> 
> Richard A Nelson wrote:
> >
> > On Fri, 10 Nov 2000, Jeff V. Merkey wrote:
> >
> > > 8.11.1 has problems talking to older sendmails and qmail.  I've seen
> > > even worse problems on 8.11.1, and backreved it immediately, and the
> > > encryption stuff has a lot of build problems on Linux.
> >
> > Sounds like local build problems, possibly all the problems !
> >
> > I can assist if you want to build 8.11.1 on Linux
> > --
> > Rick Nelson
> > Life'll kill ya                         -- Warren Zevon
> > Then you'll be dead                     -- Life'll kill ya
> >
> > -
> > 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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

[Andrea Arcangeli]

On Fri, Nov 10, 2000 at 11:45:39AM -0700, Jeff V. Merkey wrote:
> > > > > [..]  Issuing the command "sendmail -v
> > > > > -q" does not flush the mail queue. [..]

So first thing to do is to check that in /etc/sendmail.cf this line is
commented out this way:

#O HostStatusDirectory=...

(if you build .cf via m4 add this line:

undefine(`confHOST_STATUS_DIRECTORY')dnl

and rebuild the .cf from the m4 source)

Then `rcsendmail reload; sendmail -q; mailq`.

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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

[Jeff V. Merkey]

Andrea,

All done.  It's already setup this way.

Jeff

Andrea Arcangeli wrote:
> 
> On Fri, Nov 10, 2000 at 11:45:39AM -0700, Jeff V. Merkey wrote:
> > > > > > [..]  Issuing the command "sendmail -v
> > > > > > -q" does not flush the mail queue. [..]
> 
> So first thing to do is to check that in /etc/sendmail.cf this line is
> commented out this way:
> 
> #O HostStatusDirectory=...
> 
> (if you build .cf via m4 add this line:
> 
> undefine(`confHOST_STATUS_DIRECTORY')dnl
> 
> and rebuild the .cf from the m4 source)
> 
> Then `rcsendmail reload; sendmail -q; mailq`.
> 
> 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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

[Andrea Arcangeli]

On Fri, Nov 10, 2000 at 12:34:40PM -0700, Jeff V. Merkey wrote:
> 
> Andrea,
> 
> All done.  It's already setup this way.

Ok. So please now show a tcpdump trace during the `sendmail -q` so we can see
what's going wrong in the TCP connection to the smtp server:

	tcpdump port smtp

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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

[Richard B. Johnson]

On Fri, 10 Nov 2000, Andrea Arcangeli wrote:

> On Fri, Nov 10, 2000 at 12:34:40PM -0700, Jeff V. Merkey wrote:
> > 
> > Andrea,
> > 
> > All done.  It's already setup this way.
> 
> Ok. So please now show a tcpdump trace during the `sendmail -q` so we can see
> what's going wrong in the TCP connection to the smtp server:
> 
> 	tcpdump port smtp
> 
> Andrea

I tried to send Jeff a 45 Megabyte file. It is still in the queue.


 FLAGS   UID   PID  PPID PRI  NI   SIZE   RSS WCHAN       STA TTY TIME COMMAND
[SNIPPED...]


   140     0    82     1   9   0    840   100 do_select   S   ?
   0:00 /usr/sbin/rpc.pcnfsd /var/spool/lpd 
   140     0    86     1   8   0   1744   364 do_select   S   ?
   0:00 sendmail: accepting connections 
    40     0  5742     1  16   0   1812   136 wait_for_tc S   ?   0:01
sendmail: ./eAAJm8V05731 vger.timpanogas.org.: client DATA 354 

It isn't a TCP/IP stack problem. It may be a memory problem. Every time
sendmail spawns a child to send the file data, it crashes.  That's
why the file never gets sent!

This is how /proc/meminfo looks right after it crashes. There has
been a lot of swapping going on.

        total:    used:    free:  shared: buffers:  cached:
Mem:  328114176 38932480 289181696        0  2293760 27115520
Swap: 139821056 10014720 129806336
MemTotal:       320424 kB
MemFree:        282404 kB
MemShared:           0 kB
Buffers:          2240 kB
Cached:          26484 kB
Active:           5576 kB
Inact_dirty:     18348 kB
Inact_clean:      4800 kB
Inact_target:      332 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:       320424 kB
LowFree:        282400 kB
SwapTotal:      136544 kB
SwapFree:       126764 kB


Cheers,
Dick Johnson

Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.


-
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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

[Andrea Arcangeli]

On Fri, Nov 10, 2000 at 03:07:46PM -0500, Richard B. Johnson wrote:
> It isn't a TCP/IP stack problem. It may be a memory problem. Every time
> sendmail spawns a child to send the file data, it crashes.  That's
> why the file never gets sent!

Sure that could be the case. You should be able to verify the kernel kills the
task with `dmesg`.

However Jeff said the problem happens over 400K and a 500K attachment shouldn't
really run any machine out of memory, so maybe this wasn't his same problem?

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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

[Jeff V. Merkey]

Andrea Arcangeli wrote:
> 
> On Fri, Nov 10, 2000 at 03:07:46PM -0500, Richard B. Johnson wrote:
> > It isn't a TCP/IP stack problem. It may be a memory problem. Every time
> > sendmail spawns a child to send the file data, it crashes.  That's
> > why the file never gets sent!
> 
> Sure that could be the case. You should be able to verify the kernel kills the
> task with `dmesg`.
> 
> However Jeff said the problem happens over 400K and a 500K attachment shouldn't
> really run any machine out of memory, so maybe this wasn't his same problem?

I think it is.  So it looks like sendmail is bombing when it attempts to
send large files. 

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/
-
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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

[Richard B. Johnson]

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

> 
> 
> Andrea Arcangeli wrote:
> > 
> > On Fri, Nov 10, 2000 at 03:07:46PM -0500, Richard B. Johnson wrote:
> > > It isn't a TCP/IP stack problem. It may be a memory problem. Every time
> > > sendmail spawns a child to send the file data, it crashes.  That's
> > > why the file never gets sent!
> > 
> > Sure that could be the case. You should be able to verify the kernel kills the
> > task with `dmesg`.
> > 
> > However Jeff said the problem happens over 400K and a 500K attachment shouldn't
> > really run any machine out of memory, so maybe this wasn't his same problem?
> 
> I think it is.  So it looks like sendmail is bombing when it attempts to
> send large files. 
> 
> Jeff 
> 

Yes. I was finally able to send Jeff a very large file. I had
to get rid of all the other memory consumers on this system.

Once it had enough memory, it got sent.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.


-
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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

[William F. Maton]

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

> Andrea Arcangeli wrote:
> > 
> > On Fri, Nov 10, 2000 at 03:07:46PM -0500, Richard B. Johnson wrote:
> > > It isn't a TCP/IP stack problem. It may be a memory problem. Every time
> > > sendmail spawns a child to send the file data, it crashes.  That's
> > > why the file never gets sent!
> > 
> > Sure that could be the case. You should be able to verify the kernel kills the
> > task with `dmesg`.
> > 
> > However Jeff said the problem happens over 400K and a 500K attachment shouldn't
> > really run any machine out of memory, so maybe this wasn't his same problem?
> 
> I think it is.  So it looks like sendmail is bombing when it attempts to
> send large files. 

Not to use the 'S-word', but we're receiving/sending biggish attachments
(7MB-9MB) under Solaris 2.6.  Could sendmail be triggering a linux bug, or
could something specific to linux be triggering a sendmail bug?

> Jeff 

wfms

-
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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

[Jeff V. Merkey]

"William F. Maton" wrote:
> 
> On Fri, 10 Nov 2000, Jeff V. Merkey wrote:
> 
> > Andrea Arcangeli wrote:
> > >
> > > On Fri, Nov 10, 2000 at 03:07:46PM -0500, Richard B. Johnson wrote:
> > > > It isn't a TCP/IP stack problem. It may be a memory problem. Every time
> > > > sendmail spawns a child to send the file data, it crashes.  That's
> > > > why the file never gets sent!
> > >
> > > Sure that could be the case. You should be able to verify the kernel kills the
> > > task with `dmesg`.
> > >
> > > However Jeff said the problem happens over 400K and a 500K attachment shouldn't
> > > really run any machine out of memory, so maybe this wasn't his same problem?
> >
> > I think it is.  So it looks like sendmail is bombing when it attempts to
> > send large files.
> 
> Not to use the 'S-word', but we're receiving/sending biggish attachments
> (7MB-9MB) under Solaris 2.6.  Could sendmail be triggering a linux bug, or
> could something specific to linux be triggering a sendmail bug?

Richard has determined that it's a low memory problem on Linux with
sendmail.  Perhaps it affects Solaris as well, try it in low memory with
a big file.

Jeff


> 
> > Jeff
> 
> wfms
-
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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

[Richard B. Johnson]

On Fri, 10 Nov 2000, Andrea Arcangeli wrote:

> On Fri, Nov 10, 2000 at 03:07:46PM -0500, Richard B. Johnson wrote:
> > It isn't a TCP/IP stack problem. It may be a memory problem. Every time
> > sendmail spawns a child to send the file data, it crashes.  That's
> > why the file never gets sent!
> 
> Sure that could be the case. You should be able to verify the kernel kills the
> task with `dmesg`.
> 
> However Jeff said the problem happens over 400K and a 500K attachment shouldn't
> really run any machine out of memory, so maybe this wasn't his same problem?
> 
> Andrea
> 

It ran out of memory. The file got sent fine after I got rid of
all the memory-consumers. Looks like a sendmail bug where they
expect to load a whole file into memory all at once before sending
it. I always thought you could read from a file, then write to
a socket. Maybe I'm old fashioned.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.


-
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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

[Jeff V. Merkey]

"Richard B. Johnson" wrote:
> 
>
> 
> It ran out of memory. The file got sent fine after I got rid of
> all the memory-consumers. Looks like a sendmail bug where they
> expect to load a whole file into memory all at once before sending
> it. I always thought you could read from a file, then write to
> a socket. Maybe I'm old fashioned.
> 
> Cheers,
> Dick Johnson
>

Claus,

Looks like your bug.  As an FYI, sendmail.rpms in Suse, RedHat, and
OpenLinux all exhibit this behavior, which means they're all broken. 
Reading an entire file into memory must be a BSD feature.  I have
enabled an SSH account for you, so you can come in and debug.  Richard
also can get in and will be helping.

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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

[Claus Assmann]

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

> "Richard B. Johnson" wrote:

> > It ran out of memory. The file got sent fine after I got rid of
> > all the memory-consumers. Looks like a sendmail bug where they
> > expect to load a whole file into memory all at once before sending
> > it. I always thought you could read from a file, then write to

On which evidence do you base this idea?

> > a socket. Maybe I'm old fashioned.

Yeah, just like us.

Please provide some proof to your claims.


> Looks like your bug.  As an FYI, sendmail.rpms in Suse, RedHat, and
> OpenLinux all exhibit this behavior, which means they're all broken. 

Sorry, this is plain wrong. sendmail does NOT read the entire
file into memory.

> Reading an entire file into memory must be a BSD feature.  I have
> enabled an SSH account for you, so you can come in and debug.  Richard
> also can get in and will be helping.

What's the machine name and what's the account?

-
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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

[Davide Libenzi]

On Fri, 10 Nov 2000, Claus Assmann wrote:
> On Fri, Nov 10, 2000, Jeff V. Merkey wrote:
> > Looks like your bug.  As an FYI, sendmail.rpms in Suse, RedHat, and
> > OpenLinux all exhibit this behavior, which means they're all broken. 
> 
> Sorry, this is plain wrong. sendmail does NOT read the entire
> file into memory.

Does sendmail use sendfile() ?


- 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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

[Claus Assmann]

On Fri, Nov 10, 2000, Davide Libenzi wrote:

[Please use a MTA that sends the e-mail only once to a given machine,
we got three copies of this]

> On Fri, 10 Nov 2000, Claus Assmann wrote:
> > On Fri, Nov 10, 2000, Jeff V. Merkey wrote:
> > > Looks like your bug.  As an FYI, sendmail.rpms in Suse, RedHat, and
> > > OpenLinux all exhibit this behavior, which means they're all broken. 
> > 
> > Sorry, this is plain wrong. sendmail does NOT read the entire
> > file into memory.
> 
> Does sendmail use sendfile() ?

No. Just do a grep on the source code.

I suspect that procmail is used which actually used to load
the entire mail into memory.
-
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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

[H. Peter Anvin]

Followup to:  <00111023290401.00203@linux1.home.bogus>
By author:    Davide Libenzi <davidel@xmail.virusscreen.com>
In newsgroup: linux.dev.kernel
>
> On Fri, 10 Nov 2000, Claus Assmann wrote:
> > On Fri, Nov 10, 2000, Jeff V. Merkey wrote:
> > > Looks like your bug.  As an FYI, sendmail.rpms in Suse, RedHat, and
> > > OpenLinux all exhibit this behavior, which means they're all broken. 
> > 
> > Sorry, this is plain wrong. sendmail does NOT read the entire
> > file into memory.
> 
> Does sendmail use sendfile() ?
> 

Or mmap()/write()?

	-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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

[Igmar Palsenberg]

> > It ran out of memory. The file got sent fine after I got rid of
> > all the memory-consumers. Looks like a sendmail bug where they
> > expect to load a whole file into memory all at once before sending
> > it. I always thought you could read from a file, then write to
> > a socket. Maybe I'm old fashioned.

Sending a 50 MB file is OK here. So it's not a TCP/IP bug. 

> Claus,
> 
> Looks like your bug.  As an FYI, sendmail.rpms in Suse, RedHat, and
> OpenLinux all exhibit this behavior, which means they're all broken. 
> Reading an entire file into memory must be a BSD feature.  I have
> enabled an SSH account for you, so you can come in and debug.  Richard
> also can get in and will be helping.
> 
> Jeff



	Igmar

-
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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

[Claus Assmann]

On Sat, Nov 11, 2000, Igmar Palsenberg wrote:
> 
> > > It ran out of memory. The file got sent fine after I got rid of
> > > all the memory-consumers. Looks like a sendmail bug where they
> > > expect to load a whole file into memory all at once before sending
> > > it. I always thought you could read from a file, then write to

As I wrote before: this is just wrong. sendmail doesn't
load the file into memory.

> > > a socket. Maybe I'm old fashioned.
> 
> Sending a 50 MB file is OK here. So it's not a TCP/IP bug. 

Ok, hopefully this reaches everyone who has been "involved"
by Jeff into this "problem".

It turned out that this was just a misconfiguration on his box
(the load average exceeded the limit of his sendmail).

Can we please close this case now? Thanks.
-
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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

[Jeff V. Merkey]

Claus Assmann wrote:
> 
> On Sat, Nov 11, 2000, Igmar Palsenberg wrote:
> >
> > > > It ran out of memory. The file got sent fine after I got rid of
> > > > all the memory-consumers. Looks like a sendmail bug where they
> > > > expect to load a whole file into memory all at once before sending
> > > > it. I always thought you could read from a file, then write to
> 
> As I wrote before: this is just wrong. sendmail doesn't
> load the file into memory.
> 
> > > > a socket. Maybe I'm old fashioned.
> >
> > Sending a 50 MB file is OK here. So it's not a TCP/IP bug.
> 
> Ok, hopefully this reaches everyone who has been "involved"
> by Jeff into this "problem".
> 
> It turned out that this was just a misconfiguration on his box
> (the load average exceeded the limit of his sendmail).
> 
> Can we please close this case now? Thanks.

There was also an issue relative to how sendmail is interpreting load
average on a linux box.  hpa@transmeta.com pointed out that perhaps you
are not factoring sleeping processes, which Linux does -- a deviation
from BSD's interpretation of load average.  With a handle like
"Assmann", deviation is proably something you already understand quite
well ...

8)

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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

[Steve VanDevender]

Jeff V. Merkey writes:
 > There was also an issue relative to how sendmail is interpreting load
 > average on a linux box.  hpa@transmeta.com pointed out that perhaps you
 > are not factoring sleeping processes, which Linux does -- a deviation
 > from BSD's interpretation of load average.

At worst it's an issue with how Linux presents load average, not with
how sendmail interprets it -- sendmail believes what the kernel tells
it.  And from the sound of it, it's not even Linux's fault -- your box
has a high load average because it's got a lot of runnable processes.

 > With a handle like
 > "Assmann", deviation is proably something you already understand quite
 > well ...

Don't be a moron.  Claus is German, Assman really is his last name and
not some "handle", and it's pronounced "Oss-man".

I'm sure we could make plenty of stupid puns with "Merkey" too.
-
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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

[David Ford]

[-- Attachment #1: Type: text/plain, Size: 549 bytes --]

>  > With a handle like
>  > "Assmann", deviation is proably something you already understand quite
>  > well ...
>
> Don't be a moron.  Claus is German, Assman really is his last name and
> not some "handle", and it's pronounced "Oss-man".

Claus is a well liked, knowledgable and well experienced person in numerous
domains.  Please don't stoop to such silly games with people's proper name.

-d

--
"The difference between 'involvement' and 'commitment' is like an
eggs-and-ham breakfast: the chicken was 'involved' - the pig was
'committed'."



[-- Attachment #2: Card for David Ford --]
[-- Type: text/x-vcard, Size: 176 bytes --]

begin:vcard 
n:Ford;David
x-mozilla-html:TRUE
adr:;;;;;;
version:2.1
email;internet:david@kalifornia.com
title:Blue Labs Developer
x-mozilla-cpt:;14688
fn:David Ford
end:vcard

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

[Jeff V. Merkey]

On Fri, Nov 10, 2000 at 06:02:28PM -0800, David Ford wrote:
> >  > With a handle like
> >  > "Assmann", deviation is proably something you already understand quite
> >  > well ...
> >
> > Don't be a moron.  Claus is German, Assman really is his last name and
> > not some "handle", and it's pronounced "Oss-man".
> 
> Claus is a well liked, knowledgable and well experienced person in numerous
> domains.  Please don't stoop to such silly games with people's proper name.

Sounded like a handle of some kind, like Santa Claus or something.  I had no 
idea.  I speak some native american, and I'm certain if I used "Oi-ach 
Ch'ei e'ho" as a a email handle, many folks would be confused, when what I 
was trying to say is my proper (non-english) name.

Jeff


> 
> -d
> 
> --
> "The difference between 'involvement' and 'commitment' is like an
> eggs-and-ham breakfast: the chicken was 'involved' - the pig was
> 'committed'."
> 
> 

Content-Description: Card for David Ford

-
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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

[Jeff V. Merkey]

On Fri, Nov 10, 2000 at 05:15:53PM -0800, Steve VanDevender wrote:
> Jeff V. Merkey writes:
>  > There was also an issue relative to how sendmail is interpreting load
>  > average on a linux box.  hpa@transmeta.com pointed out that perhaps you
>  > are not factoring sleeping processes, which Linux does -- a deviation
>  > from BSD's interpretation of load average.
> 
> At worst it's an issue with how Linux presents load average, not with
> how sendmail interprets it -- sendmail believes what the kernel tells
> it.  And from the sound of it, it's not even Linux's fault -- your box
> has a high load average because it's got a lot of runnable processes.
> 
>  > With a handle like
>  > "Assmann", deviation is proably something you already understand quite
>  > well ...
> 
> Don't be a moron.  Claus is German, Assman really is his last name and
> not some "handle", and it's pronounced "Oss-man".
> 
> I'm sure we could make plenty of stupid puns with "Merkey" too.

I had no idea, I was making a joke.  It looked like a handle, I apologize 
for being culturally ignorant of being able to distinguishing it.  

8)

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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

[Henning P. Schmiedehausen]

sendmail+ca@sendmail.org (Claus Assmann) writes:

>> Sending a 50 MB file is OK here. So it's not a TCP/IP bug. 

>Ok, hopefully this reaches everyone who has been "involved"
>by Jeff into this "problem".

So it is _once_ _again_ a Jeff "I have no clue but I know Linux-Kernel
list is cheaper than tech support or a real admin, but my real problem
sits on the chair in front of the display" Merkey problem.

This makes me puke. Again and again.

	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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

[Jeff V. Merkey]

Andre,

SSH is running on this system, so send me your IP address to add to the
hosts.allow file and I'll send you an account so you can get into the
box and see just what's happening with ssh.  Andre Hedrick has root
privileges on this machine, so if I'm ever not around, he can get into
it.  I am running 2.2.18pre19 on i right now, and was going to upgrade
to 2.2.18-pre20 this evening, but let's look into this first since Alan
may have another patch to post ....
8)

Jeff



"Richard B. Johnson" wrote:
> 
> On Fri, 10 Nov 2000, Andrea Arcangeli wrote:
> 
> > On Fri, Nov 10, 2000 at 12:34:40PM -0700, Jeff V. Merkey wrote:
> > >
> > > Andrea,
> > >
> > > All done.  It's already setup this way.
> >
> > Ok. So please now show a tcpdump trace during the `sendmail -q` so we can see
> > what's going wrong in the TCP connection to the smtp server:
> >
> >       tcpdump port smtp
> >
> > Andrea
> 
> I tried to send Jeff a 45 Megabyte file. It is still in the queue.
> 
>  FLAGS   UID   PID  PPID PRI  NI   SIZE   RSS WCHAN       STA TTY TIME COMMAND
> [SNIPPED...]
> 
>    140     0    82     1   9   0    840   100 do_select   S   ?
>    0:00 /usr/sbin/rpc.pcnfsd /var/spool/lpd
>    140     0    86     1   8   0   1744   364 do_select   S   ?
>    0:00 sendmail: accepting connections
>     40     0  5742     1  16   0   1812   136 wait_for_tc S   ?   0:01
> sendmail: ./eAAJm8V05731 vger.timpanogas.org.: client DATA 354
> 
> It isn't a TCP/IP stack problem. It may be a memory problem. Every time
> sendmail spawns a child to send the file data, it crashes.  That's
> why the file never gets sent!
> 
> This is how /proc/meminfo looks right after it crashes. There has
> been a lot of swapping going on.
> 
>         total:    used:    free:  shared: buffers:  cached:
> Mem:  328114176 38932480 289181696        0  2293760 27115520
> Swap: 139821056 10014720 129806336
> MemTotal:       320424 kB
> MemFree:        282404 kB
> MemShared:           0 kB
> Buffers:          2240 kB
> Cached:          26484 kB
> Active:           5576 kB
> Inact_dirty:     18348 kB
> Inact_clean:      4800 kB
> Inact_target:      332 kB
> HighTotal:           0 kB
> HighFree:            0 kB
> LowTotal:       320424 kB
> LowFree:        282400 kB
> SwapTotal:      136544 kB
> SwapFree:       126764 kB
> 
> Cheers,
> Dick Johnson
> 
> Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).
> 
> "Memory is like gasoline. You use it up when you are running. Of
> course you get it all back when you reboot..."; Actual explanation
> obtained from the Micro$oft help desk.
> 
> -
> 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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

[Horst von Brand]

"Richard B. Johnson" <root@chaos.analogic.com> said:
> On Fri, 10 Nov 2000, Andrea Arcangeli wrote:

[...]

> > Ok. So please now show a tcpdump trace during the `sendmail -q` so we
> > can see what's going wrong in the TCP connection to the smtp server:
> >
> > 	tcpdump port smtp

> I tried to send Jeff a 45 Megabyte file. It is still in the queue.

[...]

> It isn't a TCP/IP stack problem. It may be a memory problem. Every time
> sendmail spawns a child to send the file data, it crashes.  That's
> why the file never gets sent!

In my experience, if you try to send large messages over unreliable
networks (we sometimes see 50 or more % losses due to chronical link
overload downstream) the connection breaks up and the messages take a long
time to get out of the door. No, not just Linux; our SunOS/Solaris/Linux
mail servers have all shown the same behaviour. Makes sense: Unless the
message is sent and ACKed, it stays put. SMTP has no "resume message" AFAIK...
This could also be an explanation for this phenomemnon.
--
Horst von Brand                             vonbrand@sleipnir.valparaiso.cl
Casilla 9G, Vin~a del Mar, Chile                               +56 32 672616
-
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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

[David Ford]

I have found that lowering the MTU helps a lot.  If it is a particular route,
simply add an additional route with the lower limit set.  The tradeoff of
efficiency v.s. reliability is improved.

-d

Horst von Brand wrote:

> In my experience, if you try to send large messages over unreliable
> networks (we sometimes see 50 or more % losses due to chronical link

-- ---NOTICE

-- fwd: fwd: fwd: type emails will be deleted automatically.
      "There is a natural aristocracy among men. The grounds of this are
      virtue and talents", Thomas Jefferson [1742-1826], 3rd US President



-
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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

[Henning P. Schmiedehausen]

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

>The sendmail folks are claiming that the TCPIP stack in Linux is broken,
>which is what they claim is causing problems on sendmail on Linux
>platforms.  Before anyone says, "don't use that piece of shit sendmail,
>use qmail instead", perhaps we should look at this problem and refute
>these statements -- I think that sendmail is causing this problem.  The
>version is sendmail 8.9.3

>I can reproduce this bug on RH6.2, RH7.0, Caldera 2.2, 2.3, and 2.4,
>Suse 6.X versions, and any of these distributions with the following
>kernels.   

>2.2.14, 2.2.16, 2.2.17, 2.2.18, 2.4.0 (all).  What happens is that
>sendmail fails to forward mails with any attachments larger than 400K,
>and they just sit in the /var/spool/mqueue directory for up to a week,
>and eventually get delivered.

Jeff,

I run about three dozen sendmail server boxes (8.9.3 to 8.11.1) on all
these platforms and each one of these boxes transfer 1,000,000+ Mails
per week (yes, this is one million).

There is _no_ _such_ _bug_. Maybe you get bitten by some bogus traffic
shapers (you did read the report from Wietse, didn't you). If there
would be such a bug, I believe, that any of the 10,000+ Customers
would start complaining.

But there is no problem with mails in any size and sendmail on Linux.

And I'm pretty much annoyed that you try to use this list not as a
kernel but a general linux-support list, because you drag every single
problem that may be far out related to a kernel, because it runs on a
kernel into this list.

Pay some $$$ for professional tech support. And use this list as a
kernel development list. Not some "I have no idea but I am a Netware
buff that has some money, so you have to listen to me or I will strike
you with my anger" rant list.

	End of discussion
		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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

[willy tarreau]

Dick, have you tried a simple "strace -f -p <pid>" ?
This often gives enough info.

BTW, there's one version of sendmail that tests the
capability security hole of a previous kernel version
(2.2.15 ?), and refuses to launch if it discovers it.
It may be possible that sendmail does other tests like
this one.

Regards,
Willy


___________________________________________________________
Do You Yahoo!? -- Pour dialoguer en direct avec vos amis, 
Yahoo! Messenger : http://fr.messenger.yahoo.com
-
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: [Fwd: sendmail fails to deliver mail with attachments in /var/spool/mqueue]

[Igmar Palsenberg]

On Fri, 10 Nov 2000, [iso-8859-1] willy tarreau wrote:

> Dick, have you tried a simple "strace -f -p <pid>" ?
> This often gives enough info.
> 
> BTW, there's one version of sendmail that tests the
> capability security hole of a previous kernel version
> (2.2.15 ?), and refuses to launch if it discovers it.
> It may be possible that sendmail does other tests like
> this one.

All recent version of sendmail check the kernel if it has the famous 'I
don't drop my root privs entirely' bug. This bug isn't the issue, sendmail
complains loudly when it finds a kernel with that bug, and won't even
start.

I'm testing with a 50 MB file now.. See how it goes :)

> Regards,
> Willy


	Igmar

-
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]

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

[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

[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

[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]

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

[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

[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

[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]

"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

[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

[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

[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

[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

[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

[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

[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/

(non)importance of loadaverages

[bert hubert]

On Fri, Nov 10, 2000 at 04:03:55PM -0600, 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.

The importance people attach to loadaverages continues to amaze me. Two
systems doing the same work can have wildly different loadaverages. If I
code a big statemachine with lots of poll() interfaces, my loadaverage will
not get a lot higher then 1.

Should I forego writing a statemachine and use pthreads or fork(), the same
amount of work will keep lots of different processes busy and raise my
loadaverage wildly.

Do you now state that the second situation is somehow 'worse'?

Feel free however to stop using Linux. Or to quote the document Al refered
to 'See figure 1'.

Kind regards,

bert hubert

-- 
PowerDNS                     Versatile DNS Services  
Trilab                       The Technology People   
'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet
-
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

[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

[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

[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

[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/

[OFF] Load avarage (Re: sendmail fails to deliver mail with attachments in /var/spool/mqueue)

[Kari E. Hurtta]

Claus Assmann:
> Why does Linux report a LA of 10 if there are only two processes
> running?

[This goes out of subject]

I have learned that load avarage means

	"Processes on run queue" + 
	"process waiting disk (or short-term) I/O"

That was before Linux times.

I have seen a workstation go to show load-average 100.
That happened when NFS-server (or network) died. These
workstations were diskless, so all processes ended to
waiting of "disk" I/O.

These were Sun's diskless workstation models.

So it is not new that load average includes something else than
processes waiting for CPU.

/ Kari Hurtta

(That was on Computer Science department of University of Helsinki.)

-
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/

Wild thangs, was: sendmail fails to deliver mail with attachments in /var/spool/mqueue

[David Ford]

[-- Attachment #1: Type: text/plain, Size: 2171 bytes --]

Some wild blatherings about sendmail...

- Uses lots of memory to send a big file.
    Incorrect.  I just verified it with a 10 meg file which became a 14 meg attachment.
Sendmail consumed an additional 5 megs combined while handling the input and output v.s.
an idle daemon.  Idle is 1.8M, recv was 4.0M, send was 2.3M, no measure on the remote
side.  I sent it via pine to a remote address.

- Requires high load average allowance
    Incorrect.  Same machine barely spiked a tenth of a point for this load and dropped
back to .05.  Only time I adjusted the configured load average allowance was back in my
naive days and we got hit with 80,000 in the queue at one time from multiple spammers.
Part of this test's load came from numerous things running and the mail sending required
spinup of the drive which blocked.

- Can't send large files
    Incorrect.  I've used sendmail for the last seven years and sometimes sent emails
with attachments totally near 100 megs.  I very frequently handle mails through this
queue that are larger than 1M.

- Qmail's time has come v.s. sendmail
    I strongly disagree, I'm not the richest person or company so I frequently run most
things on one box.  Sendmail handles perfectly fine.  If your setup is hitting the sky
with load average or failing to send mails, you have a site setup problem.

- New sendmails have problems talking to old sendmails.
    Not since I discovered the problem was ECN and not sendmail.

I noticed in the original email that the system was stuck in D state on the
/sbin/modprobe for 11 nwfs attempts.  Did nobody notice this?  (load average goes up due
to IO bound procs; D state)  I have a lot of options enabled w/ all of my sendmail
setups, and most of them include patches to use SQL for the tables which requires even
more daemons to be active.

In short, sendmail does just fine on linux.  If it's not doing just fine, there's static
in the headset.  There isn't any TCP/IP issue or we would have heard a whole lot more
screeching.

End.

-d

--
"The difference between 'involvement' and 'commitment' is like an
eggs-and-ham breakfast: the chicken was 'involved' - the pig was
'committed'."



[-- Attachment #2: Card for David Ford --]
[-- Type: text/x-vcard, Size: 176 bytes --]

begin:vcard 
n:Ford;David
x-mozilla-html:TRUE
adr:;;;;;;
version:2.1
email;internet:david@kalifornia.com
title:Blue Labs Developer
x-mozilla-cpt:;14688
fn:David Ford
end:vcard

Re: Wild thangs, was: sendmail fails to deliver mail with attachments in /var/spool/mqueue

[Jeff V. Merkey]

David Ford wrote:

David,

We got to the bottom of it.  sendmail is using a BSD method to react to
load average which is different than what linux is providing.  You have
to crank up

O QueueLA = 18
O RefuseLA = 12 

on a busy Linux server since the defaults will result in large emails
never getting sent.  

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: Wild thangs, was: sendmail fails to deliver mail with attachments in /var/spool/mqueue

[David Ford]

[-- Attachment #1: Type: text/plain, Size: 1581 bytes --]

To be honest Jeff, most of my sendmail systems have default load values
and large (read created by microsoft mua) emails make it through
constantly with no distinguishable delays.  I just launched 45 "cat
core|mail david@kalifornia.com" and core is a 10 meg binary file.  It
results in a 14 meg total message size.

The load spiked to .75 and dropped back to .45 while launching.  I started
them two minutes ago and they are all in client DATA phase with the remote
MTA at the moment.  I only have 30K/s upstream.

At present the load is .10 and the net is hopping.  This isn't a power box
and the rest of the system is running as well.

My guess is that the system reporting the problem has an elevated load
average from those 11 modprobes stuck in D state.

I manage servers that transport hundreds of thousands of emails daily and
their load is minimal.  They handle large messages fine.  The only
defaults I've really had to change are the max children and some of the
timing simply because I want stalled connections (read routing loss) to
requeue quickly.

-d


"Jeff V. Merkey" wrote:

> David Ford wrote:
>
> David,
>
> We got to the bottom of it.  sendmail is using a BSD method to react to
> load average which is different than what linux is providing.  You have
> to crank up
>
> O QueueLA = 18
> O RefuseLA = 12
>
> on a busy Linux server since the defaults will result in large emails
> never getting sent.
>
> Jeff

--
"The difference between 'involvement' and 'commitment' is like an
eggs-and-ham breakfast: the chicken was 'involved' - the pig was
'committed'."



[-- Attachment #2: Card for David Ford --]
[-- Type: text/x-vcard, Size: 176 bytes --]

begin:vcard 
n:Ford;David
x-mozilla-html:TRUE
adr:;;;;;;
version:2.1
email;internet:david@kalifornia.com
title:Blue Labs Developer
x-mozilla-cpt:;14688
fn:David Ford
end:vcard

Re: Wild thangs, was: sendmail fails to deliver mail with attachments in /var/spool/mqueue

[Jeff V. Merkey]

On Fri, Nov 10, 2000 at 04:46:53PM -0800, David Ford wrote:
> To be honest Jeff, most of my sendmail systems have default load values
> and large (read created by microsoft mua) emails make it through
> constantly with no distinguishable delays.  I just launched 45 "cat
> core|mail david@kalifornia.com" and core is a 10 meg binary file.  It
> results in a 14 meg total message size.
> 
> The load spiked to .75 and dropped back to .45 while launching.  I started
> them two minutes ago and they are all in client DATA phase with the remote
> MTA at the moment.  I only have 30K/s upstream.
> 
> At present the load is .10 and the net is hopping.  This isn't a power box
> and the rest of the system is running as well.
> 
> My guess is that the system reporting the problem has an elevated load
> average from those 11 modprobes stuck in D state.

They're not modprobes, they're misnamed processes sleeping from NWFS.  
I got the fix from someone so now they display their proper names.
top displays the names correctly, ps does not.  Several people have 
verified this problem, and all you are saying is that your servers
are never heavily loaded for long periods of time, say 200 hours
at a stretch of consatnt ftp traffic?

Jeff


> 
> I manage servers that transport hundreds of thousands of emails daily and
> their load is minimal.  They handle large messages fine.  The only
> defaults I've really had to change are the max children and some of the
> timing simply because I want stalled connections (read routing loss) to
> requeue quickly.
> 
> -d
> 
> 
> "Jeff V. Merkey" wrote:
> 
> > David Ford wrote:
> >
> > David,
> >
> > We got to the bottom of it.  sendmail is using a BSD method to react to
> > load average which is different than what linux is providing.  You have
> > to crank up
> >
> > O QueueLA = 18
> > O RefuseLA = 12
> >
> > on a busy Linux server since the defaults will result in large emails
> > never getting sent.
> >
> > Jeff
> 
> --
> "The difference between 'involvement' and 'commitment' is like an
> eggs-and-ham breakfast: the chicken was 'involved' - the pig was
> 'committed'."
> 
> 

Content-Description: Card for David Ford

-
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: Wild thangs, was: sendmail fails to deliver mail with attachments in /var/spool/mqueue

[David Ford]

[-- Attachment #1: Type: text/plain, Size: 1776 bytes --]

> They're not modprobes, they're misnamed processes sleeping from NWFS.

If they're sleeping, why are they in D state?  That ups the load average.


> I got the fix from someone so now they display their proper names.
> top displays the names correctly, ps does not.  Several people have
> verified this problem, and all you are saying is that your servers
> are never heavily loaded for long periods of time, say 200 hours
> at a stretch of consatnt ftp traffic?

If I had a normally expected constant load average that came very close to the
sendmail configured limit, I would increase the limit.  That's just common
sense for an admin.  Sendmail in itself doesn't affect the load average any
more than any daemon does.

If your normal operating load is significant, and your configured limits are
close to that, you have to expect sendmail to throttle back.  It doesn't pick
large emails as it's victims, everything gets throttled.

I would suspect that if you are near the limit then your disk is blocking
causing a load spike which is detected by sendmail so sendmail throttles back.

In my experience, Linux (and others) can be very sluggish at a load of 2 and at
another time be quite responsive w/ a load of 200.  An admin should configure
limits based on that machine's load history, not any given default number.

I've run sendmail for a lot of years at a lot of places.  I've never seen this
'large emails aren't sent' issue that people have verified.  The only reason I
find valid is if the machine hovers near the limit and disk io causes the
spike.  That isn't sendmail's fault, it's a configuration fault.

-d

--
"The difference between 'involvement' and 'commitment' is like an
eggs-and-ham breakfast: the chicken was 'involved' - the pig was
'committed'."



[-- Attachment #2: Card for David Ford --]
[-- Type: text/x-vcard, Size: 176 bytes --]

begin:vcard 
n:Ford;David
x-mozilla-html:TRUE
adr:;;;;;;
version:2.1
email;internet:david@kalifornia.com
title:Blue Labs Developer
x-mozilla-cpt:;14688
fn:David Ford
end:vcard

Re: Wild thangs, was: sendmail fails to deliver mail with attachments in /var/spool/mqueue

[Andrew Morton]

"Jeff V. Merkey" wrote:
> 
> They're not modprobes, they're misnamed processes sleeping from NWFS.
> I got the fix from someone so now they display their proper names.
> top displays the names correctly, ps does not.  Several people have
> verified this problem, and all you are saying is that your servers
> are never heavily loaded for long periods of time, say 200 hours
> at a stretch of consatnt ftp traffic?

Kernel threads?  Do this:

     strcpy(current->comm, "threadname");			/* 16 char array!! */
     current->mm->arg_start = current->mm->arg_end = 0;		/* black magic */

and `ps' should be happy.
-
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: Wild thangs, was: sendmail fails to deliver mail with attachments in /var/spool/mqueue

[Andrew Morton]

Andrew Morton wrote:
> 
> "Jeff V. Merkey" wrote:
> >
> > They're not modprobes, they're misnamed processes sleeping from NWFS.
> > I got the fix from someone so now they display their proper names.
> > top displays the names correctly, ps does not.  Several people have
> > verified this problem, and all you are saying is that your servers
> > are never heavily loaded for long periods of time, say 200 hours
> > at a stretch of consatnt ftp traffic?
> 
> Kernel threads?  Do this:
> 
>      strcpy(current->comm, "threadname");                       /* 16 char array!! */
>      current->mm->arg_start = current->mm->arg_end = 0;         /* black magic */
> 
> and `ps' should be happy.

Even better, use sched.c:daemonize().
-
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: Wild thangs, was: sendmail fails to deliver mail with attachments in /var/spool/mqueue

[H. Peter Anvin]

Followup to:  <3A0C929B.EE6F7137@linux.com>
By author:    David Ford <david@linux.com>
In newsgroup: linux.dev.kernel
> 
> - Requires high load average allowance
>     Incorrect.  Same machine barely spiked a tenth of a point for this load and dropped
> back to .05.  Only time I adjusted the configured load average allowance was back in my
> naive days and we got hit with 80,000 in the queue at one time from multiple spammers.
> Part of this test's load came from numerous things running and the mail sending required
> spinup of the drive which blocked.
> 

Well, I think it does, but not because it itself is generating much of
a load.  I had it block traffic on my desktop machine while doing a
kernel compile; I run with high parallelism and the load occationally
spikes in the high 20's.  However, the machine is perfectly
responsive, and so I was a little taken back by this.

The way Linux computes the load average really does call for higher
limits than what BSD does.  This isn't inherently a "good" or "bad"
thing -- it's just a fact of life.  That being said, it probably would
be useful if the Sendmail people would provide higher default limits
in cf/ostype/linux.m4 than for other systems.

The one thing about load average that is making it a bit hard to deal
with is that workloads on modern machines tend to vary a little too
quickly for the standard load average time constants to deal well with
them.  It's probably fine for throttling down a machine that is
getting killed with requests, but not really enough to keep, say,
parallel make without a limit ("make -j" as opposed to "make -j5")
from forking the machine to the point where the make itself fails
before knowing what just hit 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: [OT] Wild thangs, was: sendmail fails to deliver mail with attachments in /var/spool/mqueue

[Bruce Guenter]

[-- Attachment #1: Type: text/plain, Size: 1263 bytes --]

On Fri, Nov 10, 2000 at 04:28:11PM -0800, David Ford wrote:
> Some wild blatherings about sendmail...

Warning:  the following will likely be seen by some as flamebait.  I've
long ago divorced myself from sendmail to save my own sanity.

> - Uses lots of memory to send a big file.
>     Incorrect.  I just verified it with a 10 meg file which became a 14 meg attachment.
> Sendmail consumed an additional 5 megs combined while handling the input and output v.s.
> an idle daemon.  Idle is 1.8M, recv was 4.0M, send was 2.3M, no measure on the remote
> side.  I sent it via pine to a remote address.

As opposed to modern mail servers which can send messages of any size
using constant sized small (well under 1M) processes.

> - Requires high load average allowance
>     Incorrect.  Same machine barely spiked a tenth of a point for this load and dropped
> back to .05.

You saw load while sending a single file?  Modern mail servers can send
without generating significant load (unless your server was a 386).
I've used older Pentium boxes that could send 60 messages at a time
without hitting .1 load.

Anyways, this is rather off topic for linux-kernel.
-- 
Bruce Guenter <bruceg@em.ca>                       http://em.ca/~bruceg/

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

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

[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

[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/

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/