sendmail fails to deliver mail with attachments in /var/spool/mqueue
A message that is not in the archive (sent off-list or not yet received): [email protected]
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
Quoted 11 lines · Jeff V. Merkey
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.
Quoted 55 lines
Jeff
Quoted 52 lines · Claus Assmann
All of these entries have an 'X':
Quoted 24 lines
Mail Queue (11 requests)
--Q-ID-- --Size-- -Priority- ---Q-Time--- -----------Sender/Recipient-----------
FAA15716X 31418 200564 Nov 9 05:01 <[email protected]>
7BIT
<[email protected]> <[email protected]>
FAA20318X 32693 201751 Nov 10 05:29 <[email protected]>
7BIT
<[email protected]> <[email protected]>
SAA01998X 34484 203865 Nov 6 18:20 <[email protected]>
7BIT
<[email protected]> <[email protected]>
QAA01341X 65091 204150 Nov 6 16:50 <[email protected]>
7BIT
<[email protected]>
SAA13390X 41368 210478 Nov 8 18:03 <[email protected]>
7BIT
<[email protected]> <[email protected]>
LAA03425X 158115 218595 Nov 6 11:27 <[email protected]><[email protected]> <[email protected]>Quoted 15 lines
QAA01343X 65091 234150 Nov 6 16:50 <[email protected]>
7BIT
<[email protected]> <[email protected]>
KAA21225X 205041 235799 Nov 10 10:26 <[email protected]>
8BITMIME
<[email protected]>
FAA20229X 1457 272283+Nov 10 05:01 <[email protected]>
(Warning: could not send message for past 1 hour)
<[email protected]>
QAA06681X 242511 272929 Nov 7 16:18 <[email protected]>
8BITMIME
<[email protected]>
PAA12261X 576306 606701 Nov 8 15:06 <[email protected]>
<[email protected]>That is, the load on your machine is too high.
3:27pm up 29 min, 2 users, load average: 10.00, 9.97, 8.50It 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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/
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
Quoted 96 lines · Jeff V. Merkey
Date: Fri, 10 Nov 2000 14:52:01 -0700
From: Jeff V. Merkey <[email protected]>
To: [email protected], [email protected]
Subject: Re: sendmail fails to deliver mail with attachments in
/var/spool/mqueueHey 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/mqueuedirectory 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
Quoted 63 lines · Jeff V. Merkey
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
Quoted 49 lines · Claus Assmann
All of these entries have an 'X':
Quoted 24 lines
Mail Queue (11 requests)
--Q-ID-- --Size-- -Priority- ---Q-Time--- -----------Sender/Recipient-----------
FAA15716X 31418 200564 Nov 9 05:01 <[email protected]>
7BIT
<[email protected]> <[email protected]>
FAA20318X 32693 201751 Nov 10 05:29 <[email protected]>
7BIT
<[email protected]> <[email protected]>
SAA01998X 34484 203865 Nov 6 18:20 <[email protected]>
7BIT
<[email protected]> <[email protected]>
QAA01341X 65091 204150 Nov 6 16:50 <[email protected]>
7BIT
<[email protected]>
SAA13390X 41368 210478 Nov 8 18:03 <[email protected]>
7BIT
<[email protected]> <[email protected]>
LAA03425X 158115 218595 Nov 6 11:27 <[email protected]><[email protected]> <[email protected]>Quoted 15 lines
QAA01343X 65091 234150 Nov 6 16:50 <[email protected]>
7BIT
<[email protected]> <[email protected]>
KAA21225X 205041 235799 Nov 10 10:26 <[email protected]>
8BITMIME
<[email protected]>
FAA20229X 1457 272283+Nov 10 05:01 <[email protected]>
(Warning: could not send message for past 1 hour)
<[email protected]>
QAA06681X 242511 272929 Nov 7 16:18 <[email protected]>
8BITMIME
<[email protected]>
PAA12261X 576306 606701 Nov 8 15:06 <[email protected]>
<[email protected]>That is, the load on your machine is too high.
3:27pm up 29 min, 2 users, load average: 10.00, 9.97, 8.50It seems as if this is broken, top shows 2 running processes and 67 sleeping.
Quoted 8 lines
Quoted 3 lines
Quoted 3 lines
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 [email protected]
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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 6 lines · 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)
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
Quoted 109 lines
David Lang
Quoted 96 lines · Jeff V. Merkey
Date: Fri, 10 Nov 2000 14:52:01 -0700
From: Jeff V. Merkey <[email protected]>
To: [email protected], [email protected]
Subject: Re: sendmail fails to deliver mail with attachments in
/var/spool/mqueueHey 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/mqueuedirectory 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
Quoted 63 lines · Jeff V. Merkey
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
Quoted 49 lines · Claus Assmann
All of these entries have an 'X':
Quoted 24 lines
Mail Queue (11 requests)
--Q-ID-- --Size-- -Priority- ---Q-Time--- -----------Sender/Recipient-----------
FAA15716X 31418 200564 Nov 9 05:01 <[email protected]>
7BIT
<[email protected]> <[email protected]>
FAA20318X 32693 201751 Nov 10 05:29 <[email protected]>
7BIT
<[email protected]> <[email protected]>
SAA01998X 34484 203865 Nov 6 18:20 <[email protected]>
7BIT
<[email protected]> <[email protected]>
QAA01341X 65091 204150 Nov 6 16:50 <[email protected]>
7BIT
<[email protected]>
SAA13390X 41368 210478 Nov 8 18:03 <[email protected]>
7BIT
<[email protected]> <[email protected]>
LAA03425X 158115 218595 Nov 6 11:27 <[email protected]><[email protected]> <[email protected]>Quoted 15 lines
QAA01343X 65091 234150 Nov 6 16:50 <[email protected]>
7BIT
<[email protected]> <[email protected]>
KAA21225X 205041 235799 Nov 10 10:26 <[email protected]>
8BITMIME
<[email protected]>
FAA20229X 1457 272283+Nov 10 05:01 <[email protected]>
(Warning: could not send message for past 1 hour)
<[email protected]>
QAA06681X 242511 272929 Nov 7 16:18 <[email protected]>
8BITMIME
<[email protected]>
PAA12261X 576306 606701 Nov 8 15:06 <[email protected]>
<[email protected]>That is, the load on your machine is too high.
3:27pm up 29 min, 2 users, load average: 10.00, 9.97, 8.50It seems as if this is broken, top shows 2 running processes and 67 sleeping.
Quoted 8 lines
Quoted 3 lines
Quoted 3 lines
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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 4 lines
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 5 lines · 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)
Those are the defaults. Jeff quoted the values from the .cf file I edited on his machine to get the e-mails through.
Quoted 7 lines
Quoted 7 lines
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 [email protected]
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)
Claus Assmann:
Quoted 2 lines
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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Followup to: <[email protected]> By author: Claus Assmann <[email protected]> In newsgroup: linux.dev.kernel
Quoted 4 lines
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
Signature · 7 lines
<[email protected]> at work, <[email protected]> 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 [email protected] Please read the FAQ at http://www.tux.org/lkml/
Quoted 9 lines · H. Peter Anvin
Followup to: <[email protected]> By author: Claus Assmann <[email protected]> In newsgroup: linux.dev.kernelQuoted 4 lines
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.
Signature · 8 lines
** [email protected] ** 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 [email protected] Please read the FAQ at http://www.tux.org/lkml/
Wild thangs, was: sendmail fails to deliver mail with attachments in /var/spool/mqueue
In reply to a message not in the archiveSome 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'."
begin:vcard
n:Ford;David
x-mozilla-html:TRUE
adr:;;;;;;
version:2.1
email;internet:[email protected]
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
In reply to a message not in the archiveDavid 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 [email protected]
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
In reply to a message not in the archiveTo 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 [email protected]" 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
Quoted 8 lines · 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
Quoted 7 lines
O QueueLA = 18
O RefuseLA = 12on 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'."
begin:vcard
n:Ford;David
x-mozilla-html:TRUE
adr:;;;;;;
version:2.1
email;internet:[email protected]
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
In reply to a message not in the archiveFollowup to: <[email protected]> By author: David Ford <[email protected]> In newsgroup: linux.dev.kernel
Quoted 8 lines
- 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
Signature · 7 lines
<[email protected]> at work, <[email protected]> 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 [email protected] Please read the FAQ at http://www.tux.org/lkml/
Quoted 6 lines · [email protected] (Jeff V. Merkey) writes:
We got to the bottom of the sendmail problem. The line:
-O QueueLA=20
and
Quoted 8 lines
-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/mqueuedirectory 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?
Quoted 4 lines
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
Signature · 9 lines
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [email protected] Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected] 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 [email protected] Please read the FAQ at http://www.tux.org/lkml/
Quoted 26 lines · Henning P. Schmiedehausen
Quoted 6 lines · [email protected] (Jeff V. Merkey) writes:
We got to the bottom of the sendmail problem. The line:
-O QueueLA=20
and
Quoted 8 lines
-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/mqueuedirectory 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?
Quoted 4 lines
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.
Quoted 8 lines
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
Quoted 12 lines
Signature · 10 lines
-- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [email protected] Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected] 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 [email protected] 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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 6 lines · [email protected] (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.
[...]
Quoted 2 lines
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.
Quoted 3 lines
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.
Quoted 3 lines
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
Signature · 9 lines
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [email protected] Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected] 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 [email protected] Please read the FAQ at http://www.tux.org/lkml/
Quoted 4 lines · Jeff V. Merkey
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.
Quoted 3 lines
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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 52 lines · Jeff V. Merkey
Quoted 26 lines · Henning P. Schmiedehausen
Quoted 6 lines · [email protected] (Jeff V. Merkey) writes:
We got to the bottom of the sendmail problem. The line:
-O QueueLA=20
and
Quoted 8 lines
-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/mqueuedirectory 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?
Quoted 4 lines
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.
Quoted 8 lines
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
HenningI 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).
Quoted 3 lines
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.
Signature · 9 lines
------------------------------------------------------------------------- Jesse I Pollard, II Email: [email protected] 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 [email protected] Please read the FAQ at http://www.tux.org/lkml/
Quoted 3 lines · J Sloan
"Jeff V. Merkey" wrote:
It is good that you raised the issue -
THanks
Jeff
Quoted 6 lines
Cheers,
jjs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
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
In reply to a message not in the archiveQuoted 1 line · David Ford
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.
Quoted 5 lines
- 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.
Quoted 3 lines
- 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.
Signature · 1 line
Bruce Guenter <[email protected]> http://em.ca/~bruceg/